What HTML 5 is and What it is Not

An update by the working group behind HTML 5 defined what HTML 5 will not do this week, both putting a limit on HTML 5’s seemingly endless ambitions and also suggesting we may someday see a final version of the standard.

When you think of standards, typically you think of a universally agreeable rulebook that stays pretty firm. Usually this is the case. HTML 4, for instance, hasn’t changed since 1999.

HTML 5, however, is a different beast. Born out of a vacuum of HTML innovation in 2004, HTML 5 started to be pieced together by the Web Hypertext Application Technology Working Group (WHATWG) as a working document. A W3C HTML 5 working document also exists, but is mostly pieced together by the working elements of WHATWG’s group.

WHATWG’s working spec is ever-changing. In fact, one of the initiators of the working document, Ian Hickson, suggested the document will continue to be worked on for years.

In one way, you can take Hickson’s comments to mean that HTML 5 is more like a permanent working document. Will there ever be a reason to stop adding to the document when an endpoint doesn’t really exist? Not so, apparently. According to an email update by the team, there are somethings HTML 5 will not do, which suggests we may see an end to HTML 5 tinkering someday.

In this week’s This Week in HTML 5 emailer, Mark Pilgrim spoke for the foundation and drew a virtual line in the sand. This is what HTML 5 will not do:

  • deprecate <textarea>
  • allow arbitrary markup in <option>
  • include an <altinput> element (reference)
  • allow authors to localize the “Browse” button that represents a file input control
  • allow authors to localize the open-file dialog that opens in response to activating a file input control
  • mandate that browsers display a progress bar during file upload
  • limit the number of selected checkboxes or options in a web form
  • allow web authors to specify a regular expression constraint on a <textarea>
  • support form controls associated with more than one form
  • change the default type of <button>
  • allow web authors to mark form fields as auto-tabbing
  • support form seeding
  • rename the HTMLCollection .length attribute to .count
  • expose a native JSON parser for web content
  • support client-side includes
  • try to compete with Docbook

Some of these functions are simply unnecessary or too ambitious at the moment, like deprecating <textarea> or allowing arbitrary markup in <option>. Others may be functions for another time when there is more time to think up better working strategies, like offloading and limiting open-file and input dialogs — something, perhaps, for the non-existent HTML 6 spec you know we’ll see someday.

See Also:

View comments