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 IRC (such as one of these permanent autoconfirmed members).


From WHATWG Wiki
< Specs
Revision as of 22:31, 5 January 2011 by Hixie (talk | contribs)
Jump to: navigation, search

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 or post on the WHATWG mailing list or say something on the #whatwg IRC channel on Freenode.

See also: Specs with editors

How to edit a spec

We have some documentation on how to write a spec that could help if you want to help out.

Specs to edit


  • A rewrite of DOM2 Traversal.
  • A rewrite of DOM2 Range -- start at http://bitbucket.org/ms2ger/dom-range -- http://html5.org/specs/dom-range.html -- use IRC for questions
  • DOM Parsing and Serialization
    • This specification should define how XML maps to DOM Core
    • This specification should define how to serialize XML
    • This specification should define XMLSerializer and DOMParser (see start for DOMParser at http://bitbucket.org/ms2ger/domparser -- use IRC for questions)
    • This specification ideally also defines Document.innerHTML and Element.innerHTML for all types of Document nodes and Element nodes.
  • User Interaction Events (onclick, onkeypress, etc).
    • e.g. need to define somewhere that if you cancel mousedown, an element can't get focus
    • cut/copy/paste events
  • window.atob
  • window.btoa
  • An API for cryptography, to generate keys and the like
  • The console.* API. [1] [2]


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

  • CSS Animation
  • CSS Gradients
    • CSSOM needs to define how Link:, <?xml-stylesheet?>, <link rel=stylesheet>, and <style> interact with the fetching algorithm, the event loop, and the parsers from HTML5.
    • CSSOM should have a mechanism for taking elements full-screen
    • it has been proposed that CSSOM have a mechanism for keeping track of when expensive-to-compute areas of the document (e.g. a canvas) are actually being rendered.
      • Add a pair of events that fire when an element is hidden and unhidden
      • Add a pair of events that fire when an element is scrolled into and out of the view
  • <?xml-stylesheet?> could do with a rewrite for integration with CSSOM; do 'load' and 'error' events fire on it?


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:

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


  • 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/20101101063413.bf1d8102.eric@bisonsystems.net)

See also

Other stuff

Some notes from the HTML5 spec about things that need doing: