Is HTML ‘complete’?
Tim Bray recently wrote an interesting post called </html> in which he stated
interest in work on “vocabulary (by which they mean the actual angle-bracketed thingies that go into HTML) seems pretty lacking.
Me, I think HTML is done. Which doesn’t mean I think that the whole Web-programming platform is in a good state…
Let’s down tools and focus on more important problems.
I agree with Tim that fixing the web platform is more important right now than adding more elements to HTML. He cites fixing the things that jQuery, Backbone, Angular, Less, DART et al are trying to fix. Those too, but I’d also cite Service Workers, Web Manifest, device APIs as things that are urgently required to bring some level of feature-parity between web and native.
But I think it’s incorrect to claim HTML is finished. We’ve been there before, with HTML 4.01 published in December 1999 and then considered “finished”. HTML5 added lots more elements, some of which are well-used (20% of the top 100,000 sites use the HTML5 doctype, 12.% of those use <header>, for example).
Some of the HTML5 elements haven’t gained good traction. I’m inclined to agree with Matthew Thomas, who wrote (in 2004!) that new elements need to have some form of User Interface:
One way of improving this situation would be to reduce the number of new elements — forget about <article> and <footer>, for example.
Another way would be to recommend more distinct default presentation for each of the elements — for example, default <article> to having a drop cap, default <sidebar> to floating right, default <header>, <footer>, and <navigation> to having a slightly darker background than their parent element, and default <header>…<li> and <footer>…</li> to inline presentation. This would make authors more likely to choose the appropriate element.
Not every manifestation of UI is visual, however. There are still many gaps in the language that have to be patched with WAI-ARIA; on the webkit blog, James Craig writes
Many of the original features of ARIA (such as dialogs, landmarks, and menus) have been adopted into recent versions of HTML as elements. However, there are interaction patterns, common on the Web since the 1990s, that still have no native support or unreliable rendering support in HTML, such as date pickers, combo boxes, tab sets, data grids, tree controls, and more. Web developers must render all these controls themselves, using custom code or a JavaScript framework.
Steve Faulkner has a list of Aria roles and properties not available in HTML5. I’m not suggesting all should become elements or attributes, but it shows that what people make constantly outpaces the semantics available in HTML.
Since the WHATWG stopped adding new elements, we’ve seen the <main> element added to the language, which although comparatively new is used on 5% of the HTML5 sites in the top 100,000. Although it has no visual UI, it hooks into assistive technologies so that users can quickly get to the main content on a page.
Similarly, <picture> and associated responsive images attributes (srcset, sizes, x and w descriptors) have been added to the language.
Brian Kardell, Léonie Watson, and Steve Faulkner are working on a spec for a Panels and Panel Sets Extension that “defines elements and attributes for constructing a panel or collection of panels based on a single interaction paradigm.”
Elsewhere, attempts at adding other useful declarative features to the language are rebuffed. For example, <table sortable> was specified (with 9 years of anecdata from Stuart Langridge) to allow data tables to be natively sorted in the browser (a very common use-case), but implementation was rejected because “Instead of trying to bake so much into the platform someone should create a web components library that supports Hixie’s spec”.
Ah, Web Components – not ready for production any time soon, totally reliant on JavaScript, and so much harder for authors to implement than adding a single attribute.
I’m encouraged by the Extensible Web Manifesto which states
We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization… We want web developers to write more declarative code, not less.
Trialling stuff out in JavaScript, and then standardising it and adding it to core HTML/ CSS is the future of standardisation, I think. So, to declare HTML “finished” is, in my opinion, premature.
(Thanks to Steve Faulkner for crunching his dataset ooh, matron to provide use stats for <header> and <main>.)
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
8 Responses to “ Is HTML ‘complete’? ”
I was pretty annoyed by that “no sortable tables” thing. “In my experience automatic data type analysis rarely works in business applications”, says the chap rejecting it, who I will bet a fiver has less experience of this than I do, which is why I wrote all the anecdata as you note. This is one of the reasons why I never updated sorttable.js to be a polyfill for the whatwg sortable tables spec.
Heh. Reminds me of this wise man who once asked me if he could quote this in his book: http://alistapart.com/comments/semanticsinhtml5#325554.
Great post Bruce.
From my point of view, it will not be “complete” before this idea becomes true:
http://richstyle.org/a-proposal-for-representing-check-boxes-and-radio-buttons-in-html6.php
🙂
I think HTML is “finished” in the sense that the W3C have proved they can’t be trusted with coming up with meaningful new elements. Just look at the endless discussions on semantics in the comments of HTMLDoctor, and look at the abomination that is for example “article”.
Meanwhile on the real internet, everyday we mostly look at elements which serve the purpose of “price” or “productDescription” or “status” or “comment”, but have no tags for them.
And you are wrong on Web Components – browser manufacturers have finally got their act together and they are coming. Soon, I promise.
the article is as shit as this website’ design
Good read BL!
HTML should never be complete, it should be in a permanent state of evolution, improving all the time.
A couple of examples that I think would go a long way…
1. Incorporate microdata/schema type data as HTML tag attributes
2. Incorporate common UI functions into browsers, typical example if I want a simple accordion, or a open/close/toggle thing I am forced to use javascript. If that was baked into HTML the world would save a ton of page weight and speed up page load times overall.
Hmm, “not ready for production any time soon” is not the message I got from Wilson’s article. There are some details to be sorted out, but I think before the end of the year we should see interoperable implementations of Custom Elements and Shadow DOM in Chrome & Firefox, and stable, well-tested polyfills for other browsers.
But over all, I agree with the rest of this. I’m firmly of the opinion that Service Workers and related technologies are critical to the future of the Web. And HTML still has plenty of scope to grow, standardising the new elements, attributes and behaviours that developers create.