what i want from a new markup spec

So it has come to pass that the W3C has decided to take the WHATWG's HTML5 on board. It will form the basis of the W3C's HTML5. The goal is to have a public draft by June - yes, this year. Given that the spec now has to endure the full process of the W3C we'll see how that goes.

Anyway, this got me to thinking: what do I really want from a new markup specification? I've talked about this before but I realised that there's a difference between what I want and what I actually hope for :)

Ultimately it comes down to quite a small subset of the overall picture - the things I genuinely wish for in daily life. There are a few elements I'd like to see created or simply supported consistently by browsers.


These are the basics, the minimum additions to fill in some blanks left by HTML 4.01.

  • An extensible, contextual heading/section system
  • A way to associate a CAPTION (or LABEL) with images and lists
  • Footnotes (which are really endnotes on the web)

It's a short list, since the reality is that the lack of decent CSS support impacts on my daily life far more than the limitations of markup. Frankly most developers out there still haven't mastered the semantics of HTML 4.01 so it's not like adding more elements will stop people making tag soup.

Meanwhile, semantics geeks like me will keep searching for the secrets of semantic alchemy with compounds and microformats. Where the markup is deficient we have ways of adding more meaning.

Although this is not an addition to a spec... I'd like to see real support for OBJECT so (amongst other things) we can replace images with the complex explanatory content required for complex graphics. Since certain popular browsers can't cope with this element, we still essentially don't have it.


On the topic of headings, HTML5 does not do what I want since it still relies on H1-H6. I gather the HEADER element is meant to do some kind of section marking but frankly on a first reading it doesn't make a heck of a lot of sense. It certainly doesn't introduce any obvious practical benefit.

XHTML2's H and SECTION system is exactly what I want. I regularly wish I could write a code fragment with a heading, without having to know the heading rank. With the H/SECTION system, I could just define the fragment as a section and know that the heading rank will be sorted out in-situ.

If you maintain a small, stable site, headings may not have ever been an issue. But if you have ever maintained the code base for a very large site, you're probably nodding your head ;)

Even for a small blog headings are a problem. In your average blog the top two heading ranks are probably handled by the site template and CMS; but subheadings in actual posts have to be written in directly with heading tags. So you're probably inserting H3 tags right into your content. Too bad if you later want to change the post pages to have the post title as the H1 - then you'd have a jump from H1 to H3. You either have to stick with the original structure; or you have what I consider an invalid heading rank jump.

Consider the same blog, with H/SECTION... you can adjust the structure around the post as much as you like - it doesn't matter. The sections and corresponding heading ranks take care of themselves.

Headings aren't glamorous. They're not uber-funky AJAX-friendly form inputs which will sparkle in the sun and inspire dancing in the street. They are bread and butter elements which we use every day. HTML has never made them easy to work with, so like it or not they would be a killer app for a markup spec.


In addition to what I do want, I think it's important to think about what a spec excludes. I think it's high time for specs to stop weakly deprecating things and flat-out remove them. I'd kill off the semantically neutral and visual-design-based elements - FONT, B, I, S, U etc... and definitely no get-out-responsibility-free cards for WYSIWYG editors!

The spec should just have them treated and rendered the same as SPAN. They're all semantically meaningless and can be replaced either with CSS or semantically-meaningful elements.

I should note that by my reading, WHATWG's HTML5 deals with B and I by creating semantic meaning for them. While that approach has some merit, I doubt the majority of developers will alter their usage according to the new semantics so those elements' usage will just be incorrect for new reasons. If everyone out there was to adopt the new semantics, I'd probably support the approach :)

wish list

These are things I want, but in the balance of things they're not the first things I'd argue to have included. That's the basics list :)

  • A dedicated caption or group label for sets of radio buttons - FIELDSET and LEGEND don't really work for long descriptions.
  • A drag-and-drop form input which is also keyboard accessible - keystroke/click to pick and keystroke/click to drop. Drag and drop is a useful paradigm but the possible solutions at the moment are not much good for keyboard or screen reader users.
  • An element to enclose extra info for assistive technology users, something a little like NOSCRIPT. Having to use CSS tricks to hide assistive content creates a clash between content and style; not to mention putting your content at risk of Google blacklisting. An element named something like ASSIST could be ignored by search engines and enabled by assistive tech like screen readers. [Note - this is a pretty sketchy idea, no doubt there are all sorts of practical issues. I'm not saying it's perfect. It's just that we need some legit way to give extra info to users who need it, without getting blacklisted from Google. A dedicated element might be the way to go - although proper support for OBJECT would help an awful lot with accessibility it still won't help the search engine issues.]

Another short list. I wouldn't say no to specific elements for navigation, but I don't think they would really fix problems. Accessibility basics give way to usability issues - if your navigation is hard to distinguish from content, it's more of a usability issue than a markup issue.

HTML5 has elements for navigation, document content, header, footer etc... I'm not a huge fan of the naming system but I can see the potential benefits. Still, such elements aren't really priorities for me. I'm still going to give users skip links and Google has no plan to reward semantics anyway. If - and it's an if - screen readers were to make use of these new semantic elements then I'd probably use them. But screen readers lag behind and users often can't afford the latest versions anyway, so we're still going to be using skip links anyway.

all i want for christmas...

So basically what I want from a new spec is a few basics that were missed the last time around. I'm not actually hanging out for bells and whistles, although HTML 5 seems full of them and no doubt we'll happily use them.

Has reality lowered my expectations? Perhaps. Will I be glad of some kind of update - something, anything - after all these years? Almost certainly. Remember it has been more than seven years since XHTML 1.0 became a recommendation. That's 70 web years - a long time between updates.

After all that time it seems that most developers had lost faith in the W3C. Taking on HTML 5 seems like the only rational way forward and it was probably the only thing the W3C could do to regain a little bit of relevance in the world of markup. The browser makers certainly seemed to have jumped ship to WHATWG's HTML 5, or were quietly preparing to do so.

When I first heard of the WHATWG I thought it was unnecessary - maybe even a little irresponsible - to break away from the W3C. Many years later I'm glad they did.

So anyway with a June deadline, here's hoping we have a new HTML spec in time for Christmas. Santa... I'll be a good boy, I promise.

Labels: , , , , , , , , , ,


  1. Anonymous Lachlan Hunt, May 14, 2007 2:36 a.m.: 

    The spec already addresses the heading issue quite well. If you want something as simple as XHTML2 provides, then just use section and h1. In that way, h1 is exactly equivalent to h in XHTML2, just with a different name. The additional h2-h6 elements and header provide for additional flexibility.

    the figure and legend elements have been introduced for dealing with image captions. A section with a heading followed by a list can deal with list captions, though this is worth thinking about a little more.

    Footnotes/endnotes have been discussed, but AFAIK, no solution has been found. It's an open issue.

    I agree with you about font, and I'm fairly certain it will be dropped.

    I've said all I'm going to say about b and i, at least for now, so I'll skip over that point.

    Labels for groups of controls is something I think would be useful, though we really need to find evidence to show why figure and legend are inappropriate for all cases. I tried arguing for group labels last year, but so far got rejected due to lack of use cases and evience that couldn't be handled with figure/legend or tables.

    AIUI, the drag and drop features were designed with keyboard accessibility in mind, though I'm not an expert on that section, so I could be wrong.

    I'm not sure sure about your proposed ASSIST element. Could you provide some use cases for when something like that would be useful, and more clearly explain what problems it would solve? It also seems like it too could be abused by spammers, since it's hidden, unless you expect search engines to completely ignore its content.

  2. Anonymous Lachlan Hunt, May 14, 2007 2:42 a.m.: 

    oops, where I was talking about form controls and said figure, I meant fieldset.

  3. Blogger 200ok, May 14, 2007 10:33 a.m.: 

    The spec already addresses the heading issue quite well.

    I disagree. I do not think that a page full of H1 elements is a good solution. H1 has an existing, established meaning and the usage you propose alters that meaning. From what you're saying, HTML5 wants to use H1 as "top heading, except when it's not - in fact it's all the headings sometimes".

    If headings are to be evaluated contextually there should be a new heading element to go along with that new approach.

    H is a generic heading element created to have a rank only in conjunction with SECTION. H1 is the document's top heading. For want of a nicer way to put it - don't mess with it ;)

    Why hold out on headings when HTML5 is peppered with new elements?

    the figure and legend elements have been introduced for dealing with image captions

    Good, I think. Although the spec really needs some examples to clarify usage. eg. 'The first embedded content element child of the figure element, if any, is the paragraph's content.'

    I think I get what that's saying but it'd be nice to see it :)

    A section with a heading followed by a list can deal with list captions

    I'd prefer the ability to explicitly associate a caption with a list. I don't think it's sufficient to rely on proximity.

    footnotes and fonts

    Footnotes are a real challenge online, I have some ideas but they're far too much for a comment ;)

    Good to hear about font - it just has to go. Let the WYSIWYG editors stick with HTML 4.01 if they can't generate CSS :)

    we really need to find evidence to show why figure and legend are inappropriate for all cases

    Thinking on this, it's largely due to the way browsers handle LEGEND - it's a pain in the bum to use them for anything more than a short description.

    They don't work very well for the long descriptions associated with some radio buttons. Consider a poll: a long question (possibly with explanatory text) with short radio button answers. You end up trying to turn LEGEND into a block element with a lot of content.

    I suspect the difficulty of using FIELDSET/LEGEND for anything beyond simple labels means there will be few use cases out there in the wild. For a long survey, for example, FIELDSET and LEGEND would be difficult to style the way your average client wants to see the content. Like most form elements they're a pain to style, so they often get skipped.


    Yes, my thought is that the element would be specified to be ignored by search engines. Otherwise it'd be spammed instantly into oblivion.

    I don't have specific use cases to hand; but I'm thinking of situations where visual cues are very difficult to adequately describe.

    Off the top of my head, something like showing context within navigation - a nav item might be placed in a STRONG element and coloured in a clearly distinct manner. Very easy to see, but for a screen reader user this is a weak context marker and it would be better to add explanatory text like "Current selection:".

    I'm sure there are better use cases, that's just a quick thought.

    Skip links are another example actually - routinely hidden (although they shouldn't be, really) and only intended for specific users. UAs could let the user enable display of ASSIST content; developers could wrap their skip navigation in an ASSIST and style it ready for display (eg. block across the top of the content).

    ASSIST could also be used to add extra preamble for complex forms.

    Anyway, as I said it's still a bit of a sketchy idea.

  4. Anonymous Lachlan Hunt, May 16, 2007 7:15 p.m.: 

    We considered introducing an <h> element, but the idea was eventually dropped for several reasons. Some reasons I can remember include the lack of good, backward compatibility and difficulty with defining its interaction with the numbered heading elements in the heading level algorithm.

    It was decided that reusing h1 to h6, instead of introducing a new element, provided the same functionality with better compatibility. For better compatibility, you are free to continue using nested sections with sequential h1 to h6 elements, which allows for a transition period.

  5. Blogger 200ok, May 17, 2007 11:47 a.m.: 

    HTML5 introduces a lot of new elements with no serious potential for backwards compatibility. Why say no to H, but yes to NAV, ASIDE, ARTICLE, M, DIALOG, etc? Wouldn't they have the same backwards compatibility issues?

    Were headings considered more important/critical or just "too bloody hard"? :)

    Regarding interaction with H1-H6; shouldn't they take their cues from the existing structure and go from there? Thinking of a heading order like this:
    H - treat as H1, no preceding heading so it must be the top level.
    H - treat as H3, it's preceded by an H2.
    H - treat as H4, it's preceded by an H3 which "reset" the order.

    For better compatibility, you are free to continue using nested sections with sequential h1 to h6 elements, which allows for a transition period.

    "Transition period" implies that there'll be something to move on to, logically I would expect that would be the addition of H. If that's the case, why wait? Browsers can't/won't support H if it's not in the spec. Leaving it out based on compatibility opens up a catch 22.

  6. Anonymous Anonymous, May 18, 2007 12:32 a.m.: 

    The "get-out-responsibility-free card for WYSIWYG editors" is ludicrous. It makes the HTML 5 spec look like it was written by kids just out of high school. Oh, ya, it was :-)