A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Specs/todo: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
(APNG is done! And ICO is not.)
 
(97 intermediate revisions by 10 users not shown)
Line 1: Line 1:
HTML5 doesn't stand alone, it's just one of many specifications that form part of the Web platform. Many of these are currently orphaned or neglected; if you want to help, you could try editing one!
There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].
* CSS3 - there's a [http://www.w3.org/Style/CSS/current-work whole slew] of specifications for extending CSS that are in need of editors. In particular:
** the CSS3 Flexible Box module
** animation
** gradients
* updates to DOM2 Traversal and DOM2 Range.
* CSSOM - the specification for scripted manipulation of style, both the existing interfaces and new interfaces to make it easier. (Parts are being done by Anne at the moment.)


== Platform ==


These sections of HTML5 could easily be taken out and make into independent specs:
* [https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html HTML Editing APIs]
* 2d context for canvas (this is pretty stable right now, so it would probably be a bad time to work on it)
* multipart/form-data
* 3d context for canvas
* SVG
* ICO (if it contains multiple images, which one is used?)
* Animated [[GIF]]s need a spec that, in particular, specifies how to handle timings (not all browsers honor all values, so we should specify what needs to be honored exactly)
* [[Wikipedia:Robots.txt|robots.txt]]
* A specification that defines how XML maps to DOM Core. (This could be in DOM Parsing and Serialization or HTML if XML does not get updated.)
* HTTP (error handling in particular, might become less of an issue if we're successful in removing it in favor of HTTPS)
** Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/[email protected])


== APIs ==


These specs currently have active editors, but have historically spent time abandoned:
* User Interaction Events (onclick, onkeypress, etc).
* DOM3 Events
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus
* Keyboard Events -- .charCode, .keyCode, and related stuff (mostly defining legacy interfaces)
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]
* setTimeout
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)
* Web DOM4 Core -- culling the server-side features from DOM3 Core, adding features that would help the web, adding generic exceptions that would help other specs out.
** https://w3c.github.io/uievents/
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html
* [[DOM XPath]]
* [[DOM XSLTProcessor]]


== CSS ==


See also:
There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:
* http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html
* Hit Testing (see http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html)
* [Needs Specification]
* Form control styling (see [https://github.com/domenic/html-as-custom-elements HTML as Custom Elements])
* Replaced Content
** http://dev.w3.org/csswg/css3-content/ (Do we still want this or is the component model sufficient?)
* an imperative model of box-tree construction
 
== Registries ==
 
Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:
 
* MIME types
* URL schemes
 
It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).
 
See also: [[Registries]]
 
== Other stuff ==
 
http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.
 
== Stuff we managed to specify eventually ==
 
* innerText and outerText
** http://perfectionkills.com/the-poor-misunderstood-innerText/
** https://github.com/whatwg/compat/issues/5
** https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute
* data: URLs
** https://fetch.spec.whatwg.org/#data-urls
* Table Layout
** http://dbaron.org/css/intrinsic/
** http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
** https://drafts.csswg.org/css-tables-3/
* The console.* API
** https://github.com/DeveloperToolsWG/console-object
** http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694
** http://www.w3.org/mid/[email protected]
** http://sideshowbarker.github.com/console-spec/
** https://console.spec.whatwg.org/
* APNG
** https://w3c.github.io/PNG-spec/
 
[[Category:Spec coordination|*]]
[[Category:Specification editing]]

Latest revision as of 13:10, 25 January 2024

There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact [email protected], post on the WHATWG mailing list or say something on IRC.

Platform

  • HTML Editing APIs
  • multipart/form-data
  • SVG
  • ICO (if it contains multiple images, which one is used?)
  • Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honor all values, so we should specify what needs to be honored exactly)
  • robots.txt
  • A specification that defines how XML maps to DOM Core. (This could be in DOM Parsing and Serialization or HTML if XML does not get updated.)
  • HTTP (error handling in particular, might become less of an issue if we're successful in removing it in favor of HTTPS)

APIs

CSS

There are many specifications for extending CSS that are in need of editors. The most important ones are:

Registries

Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:

  • MIME types
  • URL schemes

It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).

See also: Registries

Other stuff

http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.

Stuff we managed to specify eventually