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
(→‎CSS: Added Table Layout)
(APNG is done! And ICO is not.)
 
(34 intermediate revisions by 8 users not shown)
Line 1: Line 1:
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]]. [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031666.html This mailing list post] has some advice on the matter.
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]].
 
See also: [[Specs|Specs with editors]], [[Howto spec]].


== Platform ==
== Platform ==


* A specification that defines how XML maps to DOM Core. (I think this should be in DOM Parsing and Serialization. Well really in XML.)
* [https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html HTML Editing APIs]
* X-Frames-Options
* multipart/form-data
* 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 ==
== APIs ==
Line 12: Line 17:
* User Interaction Events (onclick, onkeypress, etc).
* User Interaction Events (onclick, onkeypress, etc).
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus
* An API for cryptography, to generate keys and the like
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]
* The console.* API. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694] [http://www.w3.org/mid/[email protected]] [http://sideshowbarker.github.com/console-spec/]
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)
* setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]
** https://w3c.github.io/uievents/
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html
* [[DOM XPath]]
* [[DOM XPath]]
* [[DOM XSLTProcessor]]


== CSS ==
== CSS ==


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:
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:
* Table Layout
* Hit Testing (see http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html)
* 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 ==
== Registries ==
Line 28: Line 38:


* MIME types
* MIME types
* Schemes
* URL schemes


It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).
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]]
See also: [[Registries]]
== MISC ==
* an API to do syntax highlighting on  <textarea>, <pre>, and contenteditable sections would be highly popular with Web developers (ack Ryan Johnson). (This would probably best be done as some sort of output filter at the CSS level, rather than anything HTML-specific.)
* JS changes: [[Web ECMAScript]]
* Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honour all values, so we should specify what needs to be honoured exactly)
* Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/[email protected])
* innerText and outerText, if browsers don't remove them entirely


== Other stuff ==
== Other stuff ==
Line 45: Line 48:
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.
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.


Some notes from the HTML5 spec about things that need doing:
== Stuff we managed to specify eventually ==


* support access Array element via () instead of [] (IEism) https://bugzilla.mozilla.org/show_bug.cgi?id=289876
* innerText and outerText
* Need to say that NodeList's items are enumerable, so that... for (var x in myNodeList) { }  ...works. (ack Dethe Elza)
** http://perfectionkills.com/the-poor-misunderstood-innerText/
* a way to show icons for file types e.g. http://www.gadgetopia.com/2004/05/04/FileIconTag.html (this should probably be a function for the 'content', 'background-image' and 'list-style-image' properties in CSS)
** https://github.com/whatwg/compat/issues/5
** Maybe something like moz-icon://? http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0255.html, http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html
** 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/d7be01cb7077$4dd45010$e97cf030$@gmail.com
** http://sideshowbarker.github.com/console-spec/
** https://console.spec.whatwg.org/
* APNG
** https://w3c.github.io/PNG-spec/


[[Category:Spec_coordination]]
[[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