Semantics in HTML 5
Issue № 275

Semantics in HTML 5

by
Published in Browsers, HTML

I’m going to make a bold prediction. Long after you and I are gone, HTML will still be around. Not just in billions of archived pages from our era, but as a living, breathing entity. Too much effort, energy, and investment has gone into developing the web’s tools, protocols, and platforms for it to be abandoned lightly, if indeed at all.

Article Continues Below
Article Continues Below

Let’s stop to consider our responsibility. By an accident of history, we are associated with the development of an important tool our civilization will use to communicate for decades to come. So, when we turn our minds, idly or in earnest, to improving HTML, we must understand just how far-reaching the ramifications of today’s decisions may be.

HTML 5, the W3C’s recently redoubled effort to shape the next generation of HTML, has, over the last year or so, taken on considerable momentum. It is an enormous project, covering not simply the structure of HTML, but also parsing models, error-handling models, the DOM, algorithms for resource fetching, media content, 2D drawing, data templating, security models, page loading models, client-side data storage, and more.

There are also revisions to the structure, syntax, and semantics of HTML, some of which Lachlan Hunt covered in “A Preview of HTML 5.”

But for this article, let’s turn solely to the semantics of HTML. It’s something I’ve been interested in for many years, and something which I believe is fundamentally important to the future of HTML.

The BBC recently announced that they would drop the hCalendar microformat from their program listings, due to accessibility and usability concerns with the abbr design pattern. This demonstrates that we have, beyond any doubt, pushed the semantic capability of HTML far past what was ever intended, and indeed, what is reasonably possible with the language. We have simply run out of HTML elements and attributes with which to mark up more richly semantic documents. If we continue to be clever with the existing constructs of HTML, more problems such as this will arise. But HTML suffers from a fundamental defect as a semantic markup language—its semantics are fixed, not extensible.

This is not simply a theoretical problem. Hundreds of thousands of developers use the class and id attributes of HTML to create more richly semantic markup. (They also use them as “hooks” for CSS styling, but that’s another matter.) Almost invariably, those developers use ad hoc vocabularies—that is, values they have made up, rather than values taken from existing schemas. It’s pseudo semantic markup at best.

Many pages around the web use microformats to add more structured semantics than available in HTML’s impoverished set of elements and attributes. In this case, the values used for the class attribute come from agreed-upon vocabularies, sometimes adopted from other standards, such as vCard, sometimes from newly minted vocabularies where no solid pre-existing standard exists (as is the case for hReview).

Extensible semantics#section2

There is a very real problem that needs to be solved here. We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics—not pseudo semantics—to their markup. This is perhaps the single most pressing goal for the HTML 5 project.

But it’s not as simple as coming up with a mechanism to create richer semantics in HTML content: there are significant constraints on any solution. Perhaps the biggest one is backward compatibility. The solution can’t break the hundreds of millions of browsing devices in use today, which will continue to be used for years to come. Any solution that isn’t backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.

The solution must be forward compatible as well. Not in the sense that it must work in future browsers—that’s the responsibility of browser developers—but it must be extensible. We can’t expect any single solution we develop right now to solve all imaginable and unimaginable future semantic needs. We can develop a solution that can be extended to help meet future needs as they arise.

These two constraints in tandem, present a huge challenge. But in the context of a language whose major iterations arrive a decade apart, and whose importance as a global platform for communication is paramount, this is a challenge that must be solved.

So, how is HTML 5 addressing this issue? HTML 5 introduces a number of new elements. Some of these are what I’ve termed “structural”—section, nav, aside, header, and footer.  The dialog element is a kind of content element, akin to blockquote. There are also a number of data elements, such as meter, which “represents a scalar measurement within a known range, or a fractional value; for example disk usage,” and the time element, which represents a date and/or a time.

While these elements might be useful, and seem to have generated some interest, do they really solve the problem we’ve identified, particularly within the twin constraints of forward and backward compatibility?

Let’s consider each constraint.

Backward compatibility#section3

How do current browsers handle these new elements, such as section? Well, the most recent versions of Safari, Opera, Mozilla, and even IE7 will all render a page as follows.

<h1>Top Level Heading</h1> <section>
   <h1>Second Level Heading</h1>
   <p>this is text in a section element</p>   <section>
    <h1>Third Level Heading</h1>
   </section>
 </section>

It looks like an excellent start. But when we try styling, for example, section elements with CSS that looks like this:

section {color: red}

…most of the above-mentioned browsers manage to style the element, but IE7 (and so presumably 6) do not.

So we have a serious backward compatibility issue with 75% of browsers currently in use. Given the half-life of Internet Explorer, we can predict that most users will be using IE6 or IE7 even several years from now.

If HTML 5 introduces these new elements, what is the likelihood they’ll be implemented by the vast majority of developers—given the knowledge that they’re essentially incompatible with the majority of browsers in use?

Unfortunately, if you are looking for alternative solutions to the CSS problem, putting class attributes on your section elements and then trying to style them using the class value won’t work in IE. Perhaps there is some kind of workaround out there, but unless there is, that looks like a deal breaker right there.

Let’s turn to forward compatibility, the second constraint.

Forward compatibility#section4

We’ll start by posing the question: “why are we inventing these new elements?” A reasonable answer would be: “because HTML lacks semantic richness, and by adding these elements, we increase the semantic richness of HTML—that can’t be bad, can it?”

By adding these elements, we are addressing the need for greater semantic capability in HTML, but only within a narrow scope. No matter how many elements we bolt on, we will always think of more semantic goodness to add to HTML. And so, having added as many new elements as we like, we still won’t have solved the problem. We don’t need to add specific terms to the vocabulary of HTML, we need to add a mechanism that allows semantic richness to be added to a document as required. In technical terms, we need to make HTML extensible. HTML 5 proposes no mechanism for extensibility.

HTML 5, therefore, implements a feature that breaks a sizable percentage of current browsers, and doesn’t really allow us to add richer semantics to the language at all.

Several questions remain about the new elements. Where have these new element names come from? How was it decided that there should be a navigation element, and that it should be called “nav”? Why should the same term apply to page-level, site-level, and meta-site-level navigation?

Why not adopt an existing vocabulary, such as Docbook? Its document structure vocabulary is far richer and it’s been developed by publishing experts over many years. This is not an argument in favor of Docbook, specifically: the point is that the extremely important task of providing a mechanism for semantic richness in HTML is being approached in an ad hoc way, paying apparently little attention to best practices in related work going back 30 years or more. (The original work on GML began in the early 1970s.)

Some thoughts on a solution#section5

So, having been critical of current efforts, do I have any practical suggestions on how to solve this problem? Well, I have the start of one.

If adding elements to HTML is out of the question, at least within the parameters of this discussion, attributes are the other logical area of HTML to concentrate on. After all, for nearly a decade, we’ve been using class and id attributes as mechanisms to extend the semantics of HTML. A great many developers are familiar and comfortable with this. The microformats project demonstrated that the existing attributes of HTML are not sufficient, as a generalized mechanism, to extend the semantics of HTML. So, if we are to use attributes to help solve this problem, we need to come up with one or more new attributes. Before we get into the mechanics of how that might work, it’s only fair to subject this suggestion to the same requirements we have for the new elements of HTML 5. Most importantly, is introducing new attributes to HTML backward compatible? And if so, does it provide a workable mechanism for semantic extensibility in HTML?

Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:

<div structure=“header”>

Let’s see how our browsers fare with this.

Of course, all our browsers will style this element with CSS.

div {color: red}

But how about this?

div[structure] {font-weight: bold}

In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.

Extensibility through attributes#section6

Instead of new elements, HTML 5 should adopt a number of new attributes. Each of these attributes would relate to a category or type of semantics. For example, as I’ve detailed in another article, HTML includes structural semantics, rhetorical semantics, role semantics (adopted from XHTML), and other classes or categories of semantics.

These new attributes could then be used much as the class attribute is used: to attach to an element semantics that describe the nature of the element, or to add metadata about the element.

This is not dissimilar to the role attribute of XHTML, but rather than having a single attribute “bucket” for all element semantics, we should identify the different types of semantics for an element, and separate them out.

For example, the XHTML role attribute works like this:

<ul role="navigation sitemap">
    <li href="downloads">Downloads</li>
    <li href="docs">Documentation</li>
    <li href="news">News</li></ul>

The values of the role attribute are a space-separated list of words from the default vocabulary, or from a defined vocabulary.

Why not simply adopt the role attribute as-is? Well, there are other kinds of semantics for which the term role doesn’t apply. For example:

<p rhetoric="irony">He’s a fantastic person.</p>

This demonstrates a theoretical type of semantics—“rhetoric,” which could be used to markup the rhetorical nature of a document. This element clearly doesn’t play the role of irony in the document. Rather, the contents of the element are ironic.

Here is another example. It’s increasingly obvious that HTML lacks a way to attach a machine readable version of a humanly readable value, e.g., a date. This is at the heart of the problem the BBC has with the hCalendar microformat that we referred to earlier. While <span role=“2009-05-01”>May Day next year really doesn’t make sense, something along the lines of <span equivalent=“2009-05-01”>May Day next year would.

Again, whether we use the specific term “equivalent” or some other term for this kind of semantic attribute is not the issue. What’s important to note is that it’s not as simple as using either the class attribute or the role attribute as a one-size-fits-all bucket to hold semantic information. For a properly extensible solution that provides backward compatibility and sufficient flexibility, a solution along these lines looks worth investigating.

I titled this section “some thoughts on a solution” because a significant amount of work needs to be done to really develop a workable solution. Open questions include the following.

  • How many distinct semantic attributes should there be? Should these categories be extensible, and if so, how?
  • How are vocabularies determined?
  • Do we simply invent the terms we want, in much the same way that developers have been using class values, or should the possible values all be determined by a standardized specification? Or should there be a mechanism for inventing (and hopefully sharing) vocabularies, using some kind of profile?
  • If we have a conflict between two vocabularies, such that two identical terms are defined by two different vocabularies, how is this resolved?
  • Do we need a form of name spacing, or does some other mechanism exist?

Rather than rushing to answer these questions, I’m posing them to highlight the issues that need to be addressed, and to start a dialog. The ramifications and reach of decisions made in HTML 5 are too great for decisions to be made in the absence of at least some input from those highly knowledgeable about linguistics, semantics, semiotics, and related fields.

Hopefully, if nothing else, then it’s clear that simply “making up new elements” isn’t a solution to how to increase the semantic capacity of HTML.

Let’s not rush into these decisions lightly—after all, with climate change we’ve saddled our grandkids with enough trouble as it is. Let’s at least leave them the best possible HTML we can.

107 Reader Comments

  1. Nice article, and well said. I’ve been thinking that HTML is going to be around for the foreseeable future too, and I’ve also been thinking that HTML5 is not the future. Precisely because of the backward compatibility issues (I’ve argued before that HTML5 is not backward compatible in any practical terms: http://mattwilcox.net/archive/entry/id/957/ ) and HTML5 has limited scope (and arguably weird semantic choices – footer/header? Really?).

    Sadly, XHTML 2 isn’t the future either. Quite why HTML5 wasn’t based on the rule-set of XHTML 1.1 and expanded from their I do not know. You’ve got some neat ideas about solutions, but considering how badly off track and how far down the road HTML5 is, I can’t see anyone abandoning it in favour of a technically preferable solution. That’s exactly why XHTML hasn’t been adopted by the vast majority of people out there.

  2. Thought-provoking stuff, John. It’s great to see some long-zoom thinking applied to markup.

    I know this wasn’t the main thrust of your article, but you mentioned the problems getting IE to style elements it doesn’t recognise. It turns out that there is a solution for this using JavaScript. By declaring, for example, document.createElement(‘section’) you can force IE to recognise the section element — and we can finally get IE to recognise the abbr element by declaring document.createElement(‘abbr’). However, Firefox 2, Camino and other older Gecko-based browsers still won’t style unrecognised elements.

  4. I love the idea of extending the attribute. I love using attributes, especially when dealing with ajax calls and saving parameters. Instead of using hidden input fields everywhere to hold data, I found it much easier to store it on to and element that is going to use that data.

  5. If it’s a truly extensible markup language you’re after, why don’t we just drop HTML in favour of XML? A custom DTD would be the only other thing you’d need; Javascript would be used to handle all widget behaviour (i.e. checkboxes).

    Of course backwards compatibility is still an issue here – IE6 doesn’t like text/XML – but we’ve have to let go of IE6 eventually.

  6. As said above; a solution already exists; its xhtml with a custom dtd – in fact thats precisely what a dtd is for.

    Also, its interesting that for years web designers have been decrying the decision to have browsers render “invalid” pages quietly and gracefully, and yet now we are supposed to decry the fact that browsers won’t magically render pages properly in a format invented after their release?

    The only thing HTML needs is a bullet in the brow.

  7. It’s good to read a thoughtful, pragmatic discussion of this topic on ALA.

    XHTML isn’t really a solution for the simple reason that there is no graceful error handling. To make the extensibility of XHTML work in the way this article talks about, you have to be using the proper XML-based MIME type. Even if you ignore IE’s lack of support for this (and no current version of IE supports application/xml+xhtml) it’s simply not going to be acceptable for users to see a YSOD because one of your includes missed out a forward slash.

    XML is a great tool for machine-generated content, but when any of your markup is written by a human it’s a lot harder to be sure that everything’s going to be written in a well-formed way

  8. Almost a year ago John Resig discussed a very interesting workaround for the issues mentioned under the “backwards compatibility” heading: You can make CSS styles apply to ‘unknown’ elements in IE by using the infamous ‘document.createElement’ JavaScript method. You can read more about it on John’s blog: http://ejohn.org/blog/html5-shiv/

  9. XML and DTD’s are a good solution. Lets create a future version of html as purely presentational, then dtd’s for microformats, then when we write a site, we create it as an XML with microformats to ensure semantic meaning of it, and transform it for presentation to xHTML.

  10. I’d have to agree with Adam Cooper’s comment. As I was reading this article, XML kept coming to my mind too. I appreciate that people don’t like its error handling, and taking that aside for the moment, even IE6 will style an XML document (I think even IE4 if anyone cares!!).

    Perhaps the XML serialization of HTML5 is an option (can’t remember if IE8 will support the required doc types and if all browsers now do incremental rendering of real XML-based content or not).

    This would then leave us with a base line of semantic elements defined in HTML 5, with the potential to extend.

    Search engines and the like may not need to care about the extra set of elements, or may support an additional set on some additional namespace (though there is also the risk of namespace explosion!).

    So, not an easy solution, but it seems like there is already a technology built for doing this. (It is also potentially easier for web authoring tools to create valid output too, and text editors already decent XML support).

    And when people don’t need the extensibility, they could use the normal HTML5 instead…?

  11. As Jeremy Keith mentioned in comment 2, the document.createElement() solution works for IE 6 and 7; and the latest non-public technical release of IE8 has fixed the bug that prevented that from working in previous betas. And given that the update cycle for Firefox is significantly faster than that of IE, waiting for Firefox 2 usage to diminish significantly enough and for users to upgrade to at least Firefox 3, which handles unknown elements reasonably well, isn’t such a big deal.

    So all the problems with introducing new elements in HTML5 either have workarounds or are rapidly becoming insignificant.

    The advantage of using elements instead of attributes is that from an authoring perspective, it can make reading markup a lot easier, since so many <div> and </div> are replaced by more meaningful names. In particular, by replacing numerous nested divs, it makes associating end tags with start tags easier (as long as authors don’t simply naively replace all divs with sections, leaving the same “divitis” problem with a different name.)

  12. John,

    you make an interesting case, yet as the comments — no matter how smart they may be too — clearly show, you fall into a common trap: you propose a solution to an unclear problem.

    Pretty much everyone in the Web community agrees that “semantics are yummy, and will get you cookies”, and that’s probably true. But once you start digging a little bit further, it becomes clear that very few people can actually articulate a reason why.

    So before we all go another round on this, I have to ask: what’s it you wanna do with them darn semantics?

    The general answer is “to repurpose content”. That’s fine on the surface, but you quickly reach a point where you have to ask “repurpose to what?”. For instance, if you want to render pages to a small screen (a form of repurposing) then

  13. It’s not good to complain about attempts to update HTML because it’s already been updated several times in the past. So why suddenly can’t we update it any more? Because of IE6?

    And if HTML5 is not the answer, we are left with two things:

    1. HTML4 as it stands, and using methods like this article suggests to bolt new concepts on to it. That sounds like trying to improve VHS instead of moving to DVD just for the sake of backwards compatibility. Things have to move on at some point and often that means a big change that will leave existing users behind. (Anything that no longer works simply has to be converted, like VHS tapes are copied onto DVDs.)

    2. XHTML. This allows any tags we want, and appeals to me because we don’t have to go with a set list of tags we are given if we don’t like them. So long as they remain readable and have a DTD to let the browser know how to handle them what’s the problem?

    HTML5 may not be perfect but we can’t stick with HTML4 forever. I’m looking forward to HTML6 and beyond.

  14. Good piece, Jon – especially as I’m currently weeping in frustration while trying to style html 5 reliably.

    There are some wierdnesses in HTML 5, I agree. hr has always annoyed me, as it’s presentational and should really be “seperator” (so Japanese people can have a vertical rule). But backwards compatibility is a design principle of HTML 5http://www.w3.org/TR/html-design-principles/.

    header and footer have caused woe and anguish to some; to me, they’re well-established terms for “branding stuff” and “stuff at the end in small type that you hide the legal stuff and the accessibility link”.

    I had a fist-fight with Lachlan only yesterday because I can’t mark up dialogues using blockquotes, but must use the crazy dd/ dt pairs (and can’t mark up stage directions in a dialogue).

    But HTML 5 is probably the best thing we’ve got right now. It gives lots of new methods to markup web apps, so pushes a pitchfork in the face of the advancing Silverlight and Flash onslaught. (Do they have much richer semantics?)

    Devils advocate: you claim that microformats show that we need more semantics. But apart from hCalendar and hCard, nobody really uses them that I kmow of. Are they a solution in search of a problem?

    Devil’s advocate:

  16. I’ve often wondered about defining semantics in the same way that style is defined using CSS. You could have “Semantic Sheets” which you could attach to your HTML document in much the same way that you do CSS. That would remove the whole semantics issue from HTML. But then, really, that is what XML and DTDs are supposed to do.

    Maybe we are searching for the holy grail of web authoring. A mechanism for marking up content in a semantically rich way, that is easy to use, easy to write, easy to edit, easy extend, backward compatible and forward compatible. Perhaps this is not possible? Maybe we should just accept that HTML4, whilst not perfect, is good enough?

    @Lachlan

    But isn’t HTML5, at its core, simply replacing one fixed set of tags with another? The new tags might be meaningful now, but will they be in 30 years time?

    I personally feel too much time is wasted on creating a “better” HTML when really it is still incredibly difficult for non-technical people to write valid, meaningful and uncluttered HTML. I still know of no editor (WYSIWYG or otherwise) which I could give to my mother so that she can write a valid, sematically correct and uncluttered HTML document.

  17. Thoughtful, certainly, but i will argue for a scorched-internet policy. We need to move forward, and screw the browsers that refuse to come along with us into the future. Sure, users will suffer at first, until they Get It. Word will spread soon enough that there are browsers out there that JPW.

    Does anyone seriously believe that we can get by just on minor modifications to the current HTML spec for the next decade?? Of course not! Sooner or later, we’re going to wish we had a continuous supply of new elements, where such things make sense, universally speaking.

    Damn the torpedoes – full speed ahead!

  18. Hi John,

    The main problem you describe — of having a need to add semantics at a number of different layers within a document — is exactly what motivated me to write the early drafts of RDFa, a few years ago. And the combination of RDFa and @role achieve pretty much everything you rightly suggest we need.

    The essential difference between the attributes added by RDFa and the @role attribute is the level at which the semantics are applied. As you rightly point out in your examples, @role allows an author to say something about the document itself. For example, they might indicate that one part of their document is a footer, whilst another is a menu.

    The RDFa attributes on the other hand, relate to the _content_ of the document. Here an author can indicate that a link to another document is actually a link to a license. Or they could indicate that the text in an

    is actually the name of the author of the article.

    By the way, the @content attribute is used to provide a more accurate representation of some inline text, so your example:

    May Day next year

    could be written as:

    May Day next year

    You can also indicate the datatype, if needed:

    May Day next year

    Regards,

    Mark

    “http://webBackplane.com/mark-birbeck”:http://webBackplane.com/mark-birbeck

  19. To address the commenters who ask (rhetorically, I think) why we bother with backwards compatibility when that was never a concern in the late 90s: Do any of you actually _remember_ the late 90s? It sucked. There were no standards, browser compatibility was verymuch up in the air, and the leading edge was so erratic and inconsistent that nothing interesting or valuable could be discovered or formalized.

    Modern Ajax techniques are based off of ten-year-old technology. XMLHttpRequest and IFRAME methods have been possible for a very long time. Javascript hasn’t moved forward appreciably since v1.5. It took ten years of stability to develop the mature scripting frameworks and responsible development processes that we now take for granted.

    The last thing we want to do is throw out the old because we’ve outgrown it to introduce a whole new set of instabilities. The internet platform has become too mature for that to be a reasonable proposition. Instead, we should be examining processes like those proposed in this article, which emphasize small steps in the right general direction but without breaking everything that’s come before.

  20. Sounds like we all agree that we need a markup language that is flexible — something extensible. Yeah! And eXtensible markup language. Then we just need something that allows us to define the custom types in our documents. A document type definition.

    Boy it’d be great if this “XML” language existed along with support for “DTDs”…

    If we all stopped this absurd argument over which HTML 5 tags are worthwhile and moved to full XML support styled using current CSS techniques we could stop versioning the markup language used to structure the web.

    The only downside is that without a standard set of markup tags you make spidering the web much more challenging and open the doors to “What the hell are you doing?! Why is there a tag?!”

  21. Sounds like we all agree that we need a markup language that is flexible — something extensible. Yeah! And eXtensible markup language. Then we just need something that allows us to define the custom types in our documents. A document type definition.

    Boy it’d be great if this “XML” language existed along with support for “DTDs”…

    If we all stopped this absurd argument over which HTML 5 tags are worthwhile and moved to full XML support styled using current CSS techniques we could stop versioning the markup language used to structure the web.

    The only downside is that without a standard set of markup tags you make spidering the web much more challenging and open the doors to “What the hell are you doing?! Why is there a tag?!”

  22. “Any solution that isn’t backward compatible won’t be widely adopted by developers for fear of excluding readers. It will quickly wither on the vine.”

    This can’t be true, or else every standard in the world would eternally be stuck on version 1.0.

    I just watched Nicole Sullivan’s presentation “Design Fast Websites (Don’t Blame the Rounded Corners)”, and her comments on the difficulties of maintaining a site with an under-reliance on class/id attributes (using the right building blocks) makes these new HTML5 tags look pretty pointless.

    Maybe I’ve just outgrown the navel-gazing side of being a standardista, but I’m tired of articles discussing and debating the perfect evolution of HTML. HTML hasn’t really evolved since 4.01 because 4.01 is really, really good, and really lets you do 99.99% of what you could want. (A few HTML5 things might be useful, like cleaning up embedded media tags.) CSS still has room to grow, but CSS3 might finally catch up to the completeness of 4.01.

    Future growth in web dev isn’t in new standards or design, it’s entirely in information architecture and usability of sites that aggregate lots of data. I think that’s why ALA articles have seemed kind of boring and off-point lately — it’s really hard to write about a dev process that is so specific to each implementation.

  23. I wouldn’t bet the future of the web on IE6, IE7, and even IE8. All other browsers (Safari, Chrome, Opera, Firefox, etc) will support these new tags very soon after they are finalized. It’s not really a browser war this time, its more like a giant, dying, thrashing elephant. IE’s death is imminent, at least in its current incarnation, but it keeps trying.

    With Google now redirecting IE6 users to download Firefox or Chrome, I predict that IE6 will soon disappear. And once IE8 is out, Microsoft will be pushing that. IE7 will be the forgotten middle child. The sad part is IE8 doesn’t support styling these new tags either. So, maybe after going through two major (and not painless for the user) upgrades with out any real benefits, users might get sick of it. Even corporations might.

  24. One of the only coherent articles on HTML5 I’ve read, very well done.

    I do agree that while we’re waiting for HTML5 to finish (in the next 10 or 20 years) we need something in place to keep things moving forward. I’m not sure that creating another attribute is the answer.

    I’m not completely sure, but attributes like “role” seem to hold a glimpse of WAI ARIA support. Is that accurate? I haven’t heard much about it since WDN08. If it is, I think that would be a nice way to integrate greater web-app accessibility. Otherwise, I wouldn’t be sold on creating another attribute that IE6 won’t support just for the sake of doing it. The end result of no backwards compatibility may not be worth it at this point in browser evolution.

    Great read though.

    my2cents

  25. It’s interesting to note that except for Mark Birbecks comment, noone mentions RDFa. Maybe the RDFa community need to reach out better to Web UI designers. I would encourage everyone to take a look at it as it solves the problems mentioned in the article in a very flexible and non-intrusive way. For more background information, including a discussion of and comparison with microformats, please see Manu Spornys post from a few months back: http://blog.digitalbazaar.com/2008/08/23/html5-rdfa-and-microformats/

  26. This article has been talked about on #whatwg today:

    * http://krijnhoetmer.nl/irc-logs/whatwg/20090106#l-310
    * http://krijnhoetmer.nl/irc-logs/whatwg/20090106#l-512

    Many other subjects are discussed, so be prepared to skip large portions. 🙂

    What are the practical problems affecting users which “add more attributes” would solve but which class and id do not? The article states about a dozen times there’s an essential need for something like this, but gives no examples showing why.

  27. The current solution to extendeing (X)HTML are custom DTDs. However, that’s not good enough. RDFa is kind’a good, but not exactly “it” in my book, mainly because “it” too uses XML namespaces.

    I think the main reason why “(X)HTML with a custom DTD” has never appeared to be appealing is because of the DTD switch – custom DTDs (AFAIK) run in quirks mode. This alone is enough reason why no one would use a custom DTD.

    Namespaces exist in XHTML (since it’s based on XML), and they are just the perfect mechanism to add elements to the vocablulary without having a definitive standard. The problem with namespaces though (and THE reason why they haven’t been picked up) is that DTD is not namespace aware, so if you want to use namespace, you have to previously create a new DTD that includes the elements from the namespace and (what’s really funny for me) declare the xmlns:prefix attribute wherever you need to put it. That’s not exactly “plug-and-play”…

    The problem is PARTIALLY solved by XML Schema. The problem is the XHTML schema (even the 1.1 schema!!!) doesn’t allow elements from other namespaces to appear inside XHTML documents. In addition, the W3C validator doesn’t validate by Schema, but by DTD.

    A very simple solution that I would do if it was up to me, and which is forward compatible (and if you use the new elements with care, it can also be backdraw compatible) is to create an XHTML 1.2 schema that will allow ANY element to appear ANYWHERE in an XHTML document, as long as it is from another namespace.

    There is already a Schema validator at W3C, though a separated one. Let’s just switch the markup validator to the Schema validator (when the documents are parsed in XML mode that is), add the XHTML 1.2 schema as a possible choise, and it’s done. Ideally, the validator may include a list of “known namespaces” that are governed by W3C, and upon encountering others, it MAY issue a warning (but no error!) that the element may not be rendered properly everywhere.

    The possible problem in this case becomes the fact that XHTML 1.2 documents will have to either:
    -run in text/html in quirks mode (since there’s no DTD)
    -use the new MIME type (which always runs in strict mode, and thanks to the namespace will be rendered even without a DTD)
    -use content negotiation to choose between XHTML 1.0 served as text/html (and with tons of JavaScript to mimic the lost functionality) and XHTML 1.2.
    That last one is probably what’s best for the real world, but it’s actually not as hard as it may sound. It’s very easy to use PHP or any other server side language to switch MIME types, and using XSLT to convert the extension elements to XHTML 1.0 elements + JavaScript is also a possiblity or something like PHP’s XMLReader if you’re not finding XSLT fancy.

    As far the draconian handling of the new MIME type goes – I’m sick of hearing this argument over and over again when it’s just not valid in the real world (despite the fact it’s reffered to as a “real world problem”)!!! When you know XHTML, you won’t make silly mistakes like that, and if you do, you’ll correct them in an instant. If your content is managed by someone else, they’ll be entering the content from a CMS. It’s the CMS’s responsibility to validate the input before it ever gets displayed to users, so if the author is not XHTML savvy, he’ll see the error, not his viewers. Ideally, he won’t even see the error – the CMS will attempt to be “HTML”-ish by trying to guess what the author meant, and use THAT for viewers instead of the original. And if you leave your non (X)HTML savvy customers to manually edit their (X)HTML files, you’re just not a professional web dev to begin with!

    Phew… if you were able to read ALL of this comment, thank you.

  28. Yes, I too think the best possible solution is to make HTML extensible. This is a point I’ve tried to make to the HTML5 group before, but without apparent effect.

    Core HTML should be something less than HTML4, with a well-defined extension mechanism. Browsers would commonly load a set of extensions equivalent to HTML4, for existing web pages. Application writers could define new (application) semantics and override stock behaviors.

    In fact, when you look at the most advanced current practice, this is what authors are doing _now_, though limited and awkward.

    There are folk who want to use declarative markup to describe dynamic behavior – and as long as this is so we are pretty much screwed. Dynamic behavior is too various. The attempt yields massive markup but cannot cover all present or future possibilities. Better to go the other direction – reduce declarative markup to a minimum (in the standard) and allow for well-defined extensions.

    HTML is good enough as a starting point. Existing browsers can – perhaps enough for the interm – be used in this fashion. Small changes in near-future browsers could go a long way to help.

    The HTML5 standard is far larger than it needs to be, but we’re stuck as long as the standard lacks extensibility, and declarative markup is used (more than minimally) to define dynamic behavior.

  29. The main issue here is that we’re treating IE as though it has some special problems or concerns as opposed to other browser vendors. Webkit (Safari, Chrome), Mozilla, and Opera are all keeping up with the curve. Somehow they’ve managed to put together some semblance of support for HTML5 very quickly and get their new browsers adopted quickly.

    It doesn’t matter how this happens. Safari is Apple mandated, Chrome is auto-updated by Google and Opera and Firefox have auto-update suggestions. It’s not a question of why *can’t* old IE users upgrade, but why MS *won’t* coerce them to do so. They could easily mandate that all IE’s be up to date.

    MS is simply not interested in doing so. Who cares if we’re backward compatible with IE6? If we all start breaking the web for IE6 users, it will eventually fall into disuse. The reason IE6 still exists is because *we’re still coding for it*.

  30. Yes, we like extensibility, of course. And RDFa is a good way to go. But vocabularies of attributes will continue to be created, and will continue to evolve, as long as our needs continue to expand. That means always. None of us will ever be able to keep up with the expanding dictionary of possible attributes and qualifiers and their intricate levels of implied meaning. An intelligent system of matching relative synonyms intuitively by degree is going to be more useful than an increasingly complex set of attribute definitions.

  31. HTML 5 is completely ridiculous.

    For programmers out there, that’s the equivalent of giving somebody an MVC framework that had a blog, an image uploading site, and a forum, with no potential of creating anything else. Now you have to use those three tools together to make everything you want. Sure, if you have all three you can create a lot of stuff, but wouldn’t it be more flexible to have a file uploader tool, a database ORM, and a URI router. Seems like you could do all the same things and more without hacking it.

    Helper methods come to mind when I see the

    tag. It’s like, “Oh, we’re flexible… Look you can have sections if your header, and left nav are not enough!”.

  32. There seem to be two camps here – semantics through additional elements or semantics through additional attributes.

    For mine, the option of attribute expansion offers a shallower learning curve to new and experienced developers alike, and has excellent backwards compatibility and a greater prospect of controlled flexibility.

    And this controlled flexibility is where I imagine the library model can prove beneficial. Rather than locking in a single vocabulary – as we would with new elements – allow vocabularies to be set in the document in the same way that a JavaScript library might extend JavaScript.

    Then industry groups, communities, and knowledgeable leaders can grow – and pare – a set of vocabularies to the benefit of all. Don’t dictate a single vocabulary, but rather allow a vocabulary to flourish on its own merits.

    With JavaScript this has created the opportunity for growth, champions, debate, response, and even acceptance and adherance.

    It may smack of XHTML and it may not be the final solution, but it will help us toward a solution.

  33. bq. Given the half-life of Internet Explorer, we can predict that most users will be using IE6 or IE7 even several years from now.

    Most users are not using IE6 now. According to our corporate website IE comprises 79.9% of our visitors’ browsers — 63.4% IE7 and 16.3% IE6. All other versions have a combined total of 0.2%.

    I’d also be willing to bet that IE7 will be upgraded to IE8 much faster than IE6 was upgraded to IE7. The only real holdouts now are the large companies, who will have to upgrade from Windows 2000 sometime. I hope.

  34. A pragmatic and well written article, John—right on.

    Back “in comment 16”:http://alistapart.com/comments/semanticsinhtml5?page=2#16 Robin Massart suggested “Semantic Sheets” that extracted semantics from markup in much the same way as CSS extracts presentation. Recently, I noted that “RDF-EASE”:http://buzzword.org.uk/2008/rdf-ease/spec seems to be trying to do this, but I’m not sure this is an appropriate solution. Fundamentally, it seems to have all the same maintainability issues as the traditional RDF-XML for semantics plus HTML for document publishing duality had.

    In other words, despite RDF-EASE claiming a simpler syntactic implementation than RDF-XML, I fear segregating the semantics of a document from the actual structural markup is far more backwards and forwards incompatible than incrementally improving the mix of the two, as RDFa does with its attributes. That’s one of the major things I really like about RDFa, and with the suggestion that HTML5 semantic focus should be attributes, and not elements—it’s “all in one,” but _not_ “one size fits all.”

    Following from that, and acting as my own devil’s advocate to some degree, a question. As John has been saying (for quite some time, mind you) there seem to be different “kinds of” semantics, including structural, content, and relational. Given the obvious need for future extensibility, are the purposes of these semantics distinct enough that they warrant their own interfaces? Is it _good_ that semantics seem to have found their way into elements, attributes, attribute values, entirely separate companion documents, and now perhaps even “semantic style sheets” or is that _bad_? How far away from “real content” is too far for semantics?

    I really have no idea, so I’m strongly in favor of getting linguistics and semiotics experts involved in all this so we can hash things out with them, too. 😉 Anyway, great article, and good discussion”¦one of the too few ALA articles in which I’ve really enjoyed reading through all the comments.

  35. bq. It’s increasingly obvious that HTML lacks a way to attach a machine readable version of a humanly readable value, e.g., a date.

    Specifically for date/time values, which have proven to be a problem, HTML5 has proposed “the *time* element”:http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element

    It should be possible for microformat parsers to read into the datetime attribute to extract the machine readable value, without any unwanted side effects (as those noted with abbr@title).

    This seems a very clear and useful step forward to me, and an example how the peeps behind HTML5 have been working to address current and pressing markup problems.

  36. Outstanding article john, finally some sanity for a html 5 migration path. Otherwise html 5 will just die a death as the corporate world can’t migrate to it with easy.

    All very well having a new spec, but it becomes just a academic plaything (sorry html5 WG) if one can’t migrate to it with ease.

  37. The suggestions for DTDs are on the right track, but the more generic schema is perhaps more appropriate. A DTD provides no way of extending semantics. Creating more attributes or more elements doesn’t provide extensibility, either. We must use an extensible language for assigning semantics. RDF comes to mind.

    How about this? XML documents whose language is described by some schema which describes not only data type but ascribes semantics to the document type. Perhaps we already have this on the standards and authoring side. What the world lacks is XML browsers.

    To solve the problem of backwards compatibility, I echo the idea of building the future Web in (extensibly) semantic XML with a transformation (not necessarily client-side) to some version of HTML for backwards compatibility.

  38. In comment 35 Ben Boyle raises the possibility of the HTML5 proposed datetime element replacing the misguided microformat use of the title attribute. However, I think that serves as an excellent example of the problems raised in this article: that of the non-backwards compatible approach WhatWG has decided to pursue with HTML5. All this microformat needs is an attribute such as ‘datestamp’ which might be used with any element (such as SPAN) to replace the human-readable title attribute. But instead of simply introducing an attribute which parses consistently and correctly in legacy browsers, WhatWG proposes introducing an entirely new element that will not parse consistently in legacy browsers. Take a look at XHTML2. It adds greater authoring flexibility by globalizing its attributes: something HTML5 could benefit from without breaking backwards compatibility with legacy browsers (or at least degrading gracefully in those browsers). And XHTML2 does this despite being an XML application and not having the same problems introducing new elements that HTML5 has.

    If an element is necessary then I would say go ahead an introduce an element. But time and time again, WhatWG introduces elements when attributes would be more appropriate for many reasons.

    On another topic, several here have raised the possibility of XML and schema definitions (such as DTD, XSD, and RelaxNG). Certainly these have been some great advances in technology. However, they have the deficiency of not being owned by Microsoft, so we have Microsoft refusing to support XHTML in their market leading browser. This means that one can use XML, but lose features of HTML (such as link activation which cannot be expressed in a DTD) or not use XML and be stuck with the same set of elements from the 1990s.

    One way forward might be to bring XML namespaces to the text/html serialization of HTML. IE6 through IE8 already support a slight variation on XML namespace, but the other browsers only support XML namespaces with XML proper. With XML namespaces in text/html, different communities of authors can introduce new elements and have them parsed correctly even within text/html and even without schema definitions (if that’s desirable).

  39. @Jon Wolski
    Look at my last comment (27) – having a Schema doesn’t (on its own) guarantee that you’ll be able to plug in other elements. You have to explicitly allow this in the Schema, and the existing official XHTML ones don’t allow that. If they did though, what you say is exactly what I’d have done too.

    @Rob Burns
    You’re confusing the usage of plain XML with extending XHTML. XML doesn’t define links, and so browsers (as by specification) do not assume a link. XHTML defines links, so browsers assume XHTML links. XML has the hooks to make one vocabulary mix with another (namespaces), it’s just that the current form of XHTML doesn’t legally (i.e. by Schema) allow it. See my last comment for a proposed solution.

    BTW, Microsoft is not refusing to support XHTML – they’re just delaying it until they have a proper XML parser for JavaScript (the *NS() and evaluate() DOM methods in particular) and other “under the hood” fixes I’m not completely aware of. But I’ve read for a fact that the MSIE team DO have an alpha of XHTML rendering module internally. They’ve mostly waited for a way to guarantee backwards compatibility in JavaScript, and I assume the new meta elements is going to open the door to that.

  41. The article is right that the backwards compatibility story of new attributes is better than that of new elements, although there is a cost in terms of code verbosity and browser behavior is slowly being repaired to make it easier to add new elements.

    I also agree that the machine data problems faced by microformats suggest that HTML needs a generic “way to attach a machine readable version of a humanly readable value”. (XHTML+RDFa and XHTML 2 provide one in the form of the ‘content’ attribute. So far, HTML5 has attempted to handle this problem on a case-by-case basis only.)

    The article claims that “HTML 5 proposes no mechanism for extensibility”, but this is manifestly untrue; HTML5 includes ‘meta’, ‘rel’, and ‘class’. The article offers no clear argument why these plus ‘equivalent’ would not provide the same sort of distributed extensibility as additional attributes suggested by the article. I agree that there are different types of semantics, but it doesn’t follow that: ‘structure=”paraphrase” rhetoric=”irony”‘ allow developers to do anything that ‘class=”paraphrase irony”‘ would not. The backwards compatibility story for new classes is much better than new attributes, since elements can be styled by classname without JS even in IE6.

    A rather overoptimistic view of distributed extensibility based on XML, CSS, JS, and DTDs characterizes a lot of the comments on the article.

    DTDs are a validation tool that are mostly irrelevant to distributed extensibility:

    * All DTDs do is constrain syntax and define templates (entities), they don’t tell user agents anything about language meaning or function (and the same is true of XML Schemas and RELAX NG).

    * Typical browsers don’t read them.

    * “DTDs are suboptimal for use with XML”:http://hsivonen.iki.fi/thesis/html5-conformance-checker#dtd since (for example) they are not namespace aware.

    However, pace Vasil Rangelov, custom DTDs do not necessarily trigger quirks mode.

    Sure you can invent some arbitrary XML elements and style them with CSS. But then you make your content dependent on publisher CSS for rendering, publisher JS for functionality, and publisher metadata (ARIA markup) for representation to assistive technologies and other automations. To be as media-independent as HTML, publisher CSS must be provided for all media types (screen, print, speech, handheld, etc). At the same time, user-agent and users would lose much of their current ability to customize the display and functionality of web content (e.g. through user scripts and styles).

    Yet the semantic extensibility provided seems no different than that provided by HTML 4’s ‘class’ and XHTML+RDFa’s ‘content’ attributes, while the functional extensibility provided in a backwards compatible fashion in this way is limited by what ARIA can represent – a set of roles similar to those in HTML5 already.

    This seems to be me a lose-lose situation: lots more work for developers in return for the same underlying semantics but with lots less functionality for end-users. And that’s in a best case scenario; given the general reluctance of developers to undertake accessibility measures or attempt bulletproof engineering, it’s likely that accessibility, reliability, and security (already both in a bad way) would take a nose-dive if distributed extensibility in this form became common practice.

    To allow consuming software to offer new functionality based on new semantics requires either that consumers agree with content producers about what new names (elements, attribute values, or whatever) actually mean through a social process (like writing a specification), or that consumers agree with producers on a machine process by which new meanings can be defined with code.

    HTML5 and microformats are basically taking the first approach.

    I’m not sure whether the second approach is practical. There are some ideas floating about in which new ARIA roles are defined using “RDF”:http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html#Extending or “JSON”:https://wiki.mozilla.org/Accessibility/JSON_ARIA . These go some way towards mimicking the ‘class’-model of extensibility in which new meaning/function is layered on top of more generic meaning/function to provide graceful degradation, and providing the raw materials with which a user agent could construct a user interface (for example, localized role names). I’d really like to see examples of this working in practice before making up my mind.

  42. Well written article on an important open question in the semantic web world. Bridging the gap between human- and machine-readable content is also an important concern for those of us who develop REST interfaces.

    I agree that adding elements is not a real solution to HTML’s lack of semantic depth and that any solution that is future proof needs to be extensible. Think “teach a man to fish”.

    I notice (with some surprise) that I have not seen mention of RDFa yet (http://www.w3.org/TR/xhtml-rdfa-primer/).

    Whatever the solution, it will be a while before it gains enough traction to see widespread implementation. Hopefully sites like ALA and companies with forward-looking web strategies like the BBC will lead the way.

  43. I’ve given this about 30 seconds of thought, so I apologize for any glaring holes in my logic…but:

    What about using HTML5 in conjunction with browser-specific, server-side XSL transformations?

    Depending on the browser, we could replace the HTML5 elements with browser-friendly versions…so any ‘section’ elements would be transformed into ‘div class=”section”‘ in IE7, for example.

    The CSS code would look something like:

    section, .section { color: red; }

    I hate browser forking – but this doesn’t seem like it would require that much effort. Then again, I’m probably missing an obvious flaw.

  44. @Vasil Rangelov (comment #39). Regarding confusing XML and XHTML, there may be some confusion here, but it is not mine. The suggestion of using XML I was referring to was about pure XML without XHTML. IE5 and higher support XML parsing and rendering but not XHTML aware XML parsing and rendering. It is a little naive to think Microsoft is trying to work out a few DOM methods for 10 years to get XHTML ready.

    If we were talking about using XHTML and only focussed on browsers that support it (those except IE), then the entire topic of the article would be mute. The elements would parse fine along with the attributes in any XML parser (no DTD or schema definition necessary for that). If IE supported XHTML instead of playing these games it would make every web author’s life much easier and we could easily add incremental improvements to HTML without all of this fuss. Most semantics could be added to the vocabulary with great ease with only the rare exception of adding semantics such as links or document titles that require behavior beyond what CSS provides.

    @Benjamin Hawkes-Lewis (comment #41). I agree with your assessment that some of this discussion is based on an overoptimistic assessment of the extensibility provided by schema definitions and other building blocks. However, the W3C has provided a rich set of tools for communities of authors to provide new extended vocabularies that can basically plug-in to what’s already there. With a rich (perhaps richer than today) host language such as HTML, the use of CSS for styling, XML Namespaces, ARIA role for accessibility, XInclude for embedding, XLink for linking, many of the abstract pieces of a vocabulary are low hanging fruit for an authoring community to use. With these technologies implemented in common libraries and processing applications, the extensibility would work rather well. The problems are not technical; the problems are predatory monopolistic practices.

  45. @41 “The article claims that “HTML 5 proposes no mechanism for extensibility”?, but this is manifestly untrue; HTML5 includes “˜meta’, “˜rel’, and “˜class’. ”

    Try doing SVG using only meta, rel, and class.

    The problem with telling people to use XHTML with RDFa, or SVG for that matter, is that the syntax is fault intolerant, especially the Firefox handling of errors. The Yellow Screen of Death is rather intimidating, even for professionals.

    By not having a mechanism whereby we can extend HTML5 for something as sophisticated as SVG, means that the adoption of SVG is that much slower. This deprives us of a wonderful vector-based graphics system, forcing us to continue being dependent on proprietary alternatives, such as Flash or Silverlight.

    Once we have a mechanism to extend the language for SVG, most other vocabularies would then be a piece of cake, and we have a web that doesn’t have built-in boundaries, where we have to negotiate every single, tiny little step we want to take.

  46. “Rob Burns”:http://www.alistapart.com/comments/semanticsinhtml5?page=5#44 writes:

    bq. With these technologies implemented in common libraries and processing applications, the extensibility would work rather well. The problems are not technical; the problems are predatory monopolistic practices.

    I think the technical challenges are substantial, and that none of the problems I mentioned are the result of monopolistic practice.

    Can you demonstrate that creating an XML element to represent a widget plus requisite styles for all media types, plus JS functionality, plus ARIA metadata for AT representation is no more work than progressively enhancing from a native HTML widget with some screen CSS and some unobtrusive JS? Can you explain how users can customize their experience of such widgets in the way they can customize their experience of an HTML widget?

    This isn’t a critique of ARIA; we need something to make the divitis produced by many JS frameworks more accessible and ARIA, given its rapid rate of implementation, will give us some HTML5 features before we make the switch, help to get HTML5 working in older user agents, and provide increased accessibility for non-HTML XML languages by allowing UAs to map them to desktop accessibility APIs. But the current functionality provided by ARIA is in fact an example of centralized extensibility: UAs implementing roles defined in a W3C draft. It does not yet distribute the creation of genuinely new semantic functionality to content developers – except in so far as they can simply add together small widgets to make a complex interface exactly as they’ve always done.

    Can you demonstrate that these technologies would provide any human meaning or useful function to users of a user agent not explicitly programmed beforehand to represent said meaning or provide such functionality?

    If this is demonstrable, is it also demonstrable that the same cannot be done with ‘meta’, ‘rel’, ‘class’, and ‘content’/’equivalent’ in text/html, or failing that with the addition of the ARIA attributes?

    Isn’t the difference XML makes to distributed (X)HTML extensibility essentially syntactical, since it allows extenders to use arbitrary elements as labels, while shifting downlevel meaning and function into attributes?

  47. “Shelley Powers”:http://www.alistapart.com/comments/semanticsinhtml5?page=5#45 writes:

    bq. Try doing SVG using only meta, rel, and class.

    If we lay aside the considerations that HTML5 includes ‘canvas’ and may include a text/html serialization of SVG in the future, and pretend that it also included a ‘content’/’equivalent’ attribute, I don’t see why it would be an order of magnitude harder to implement a language with the same meanings and functionality as SVG in HTML plus CSS plus JS than in (a) HTML plus attributes for different semantic types, or (b) a brand new XML language. I think all would be sort-of possible, but none would be performant (element per pixel anyone?). I think what made SVG practical was user agents implementing the necessary high-performance drawing code; it’s not an example of distributed extensibility.

  48. “http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data”:http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data

    I’m suprised this wasn’t brought up, but the hooks Mr. Allsopp is looking for appears to be already in the spec: dataset attributes.

    These attributes provide a generic template, i.e.

    These attributes even have a very nice JavaScript API: p.dataset[‘rhetoric’] = ‘irony’ and would work with CSS attribute selectors, AND work in IE6.

    John Resig wrote up “a great summary on them last year”:http://ejohn.org/blog/html-5-data-attributes/ .

    If another group, such as the Microformats community, wants to standardize the specifics of these data attributes, I don’t see anything in the current spec that prevents it, except for the following:

    bq. User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values.

    But if we can convince the HTML5 group to change “MUST” to “SHOULD,” you could chalk this up as problem solved. You could also change the attribute’s definition from:

    bq. Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

    To

    bq. Custom data attributes are intended to store custom data private to the page or application, or add semantic information for which there are no more appropriate attributes or elements.

    I’m surprised this wasn’t mentioned in the article.

  49. In comment 46 Benjamin Hawkes-Lewis says:

    bq. Can you demonstrate that creating an XML element to represent a widget plus requisite styles for all media types, plus JS functionality, plus ARIA metadata for AT representation is no more work than progressively enhancing from a native HTML widget with some screen CSS and some unobtrusive JS? Can you explain how users can customize their experience of such widgets in the way they can customize their experience of an HTML widget?

    I think we’re not that far apart in our assessment of things. I’m not suggesting that this is possible or even desirable. My goal is not to make extensibility so distributed that every web site or even every web page has its own vocabulary. Instead I want the current (largely W3C originated) standards to serve as building blocks so that broad communities of authors can add their own vocabulary to what already exists.

    So I don’t even want authors to approach the question you posed. However, I do want other communities of authors (perhaps outside the core specification framers) to be able to create other semantic vocabularies suitable for their specialized disciplines. This view of distributed extensibility has nothing to do with the divitis mess we see. There authors (and implementors) have misunderstood the tools available and reinvented the wheel but without the elegance or even the circularity of the original wheel (to extend the metaphor). In my vision of a future web, the same thing you’re challenge represents would be handled entirely within the semantics of HTML, XForms and SVG and the visual flair would be cascaded onto those semantics with a combination of CSS, XSL and SVG. So there the approach to distributed extensibility is don’t do it.

    Instead I’m interested in genuine cases where authors have semantic needs not already provided by HTML and the companion recommendations (SVG, MathML, XForms, XInclude, XLink, WAI-ARIA, CSS, XSL, etc.). For many specialized vocabularies, what’s needed is simply the ability to add specific semantics through the addition of elements, attributes or attribute values which can then be presented with a default stylesheet the spans all media types. So the specialized vocabulary (links, vector graphics, mathematics, user interface) would still be developed in a centralized way. However, the distributed extensibility would take place in a way that made significant re-use of those abstracted vocabularies for other more concrete vocabularies.

    This would require more development in core vocabularies, particularly in CSS where CSS3 brings a lot of power, but still more is needed. However, even more troublesome is the lack of implementation of these brilliant ideas that have come out of the W3C. It is this lack of implementation that I’m blaming on predatory monopolistic practices because, quite frankly, I haven’t come up with a better explanation.

    So to return to your challenge, I would say that with widespread implementation of something like XHTML2, CSS3, and SVG, an author would be insane to try to recreate all of that abstract functionality from XML alone instead of using the tools that already exist. However, in the current state of affairs an author cannot count on most browsers implementing the W3C tools that author needs to accomplish their task. We’ve seen instead the deployment of an army of sycophants who make extensive use of non-sequitur and other fallacious arguments to convince us all that square wheels are superior to circular ones (present company excluded).

    We need a strengthening of semantic markup to get a better understanding of the presentational needs of creative artists who want to present selections or booleans or triggers, etc. in all sorts of imaginative ways. By facilitating that we entirely obviate the needs of many authors to reinvent the wheel (which most are doing out of necessity without making sycophantic celebrations for this unfortunate situation).

    HTML5 on the other hand is trying to celebrate the confusion of semantics and presentation. For example HTML5 adds a new DATAGRID element which is simply another ordered list, but one presented in a grid (left-to-right rows repeated from top-to-bottom). The datagrid is clearly a presentational style authors want to use. However, it’s not the type of thing that belongs in the underlying semantic language. The change in presentation from a traditional list to a datagrid list should participate in the CSS cascade like any other presentational style. That way even the oldest of browsers and assistive technology already know that what is being presented is a list, no matter what animations and flair are occurring in the visual rendering of the list (just as one of too many examples).

  50. Great article and great discussion. I feel like I’m in a conference workshop with some of the most insightful web monkeys in the world.

    I like the concept of creating mechanisms over widgets as a philosophy in general. They enable. They allow for creativity, individuality, and cleverness that might never have existed otherwise. Its the difference between building a Lego city with roads for your Hot Wheels rather than cruising Need for Speed. Its knowing how to sear a pork chop, cut and saute an onion and make a pan sauce with some leftover white wine vs. following a recipe step by step (and having to read it a few times over to make sure you’re doing it *just right*).

    I do design and front-end development solely, working around CMSs and back-end logic to make things look pretty. So here is a perspective from someone who is less inclined to care much about DTDs, schemas and whatnots.

    I’ve written enough sites where I have to ID divs as header, content, footer, nav, sidebar, etc, but I don’t always. I’ve done plenty of top-level, secondary, and tertiary navs, but I’ve also designed sites that were 10 pages that could have been 1 (if the client was hipper, it would have been), where the concept of navigation would be meaningless. I strive for as valid and accessible as possible.

    So what good is it to add tags that I don’t need to use all the time? What problem are we solving? I see canned code being handed out instead of taking the time to learn how you can get a lot done just by tossing in some IDs and classes.

    Let’s standardize the vocabulary, sorta how microformats is doing. Its data about data and its ready to go. Build smarter parsers.

    That dataset attribute in HTML5 is about the only thing I’m really excited for.

    Oh, and the argument that new tags clean up divitis is a terrible one; you’ve cured one ailment and injected tagitis. At least a div is a div and when I think its special, I can add an ID to it.

  51. Great article and great discussion. I feel like I’m in a conference workshop with some of the most insightful web monkeys in the world.

    I like the concept of creating mechanisms over widgets as a philosophy in general. They enable. They allow for creativity, individuality, and cleverness that might never have existed otherwise. Its the difference between building a Lego city with roads for your Hot Wheels rather than cruising Need for Speed. Its knowing how to sear a pork chop, cut and saute an onion and make a pan sauce with some leftover white wine vs. following a recipe step by step (and having to read it a few times over to make sure you’re doing it *just right*).

    I do design and front-end development solely, working around CMSs and back-end logic to make things look pretty. So here is a perspective from someone who is less inclined to care much about DTDs, schemas and whatnots.

    I’ve written enough sites where I have to ID divs as header, content, footer, nav, sidebar, etc, but I don’t always. I’ve done plenty of top-level, secondary, and tertiary navs, but I’ve also designed sites that were 10 pages that could have been 1 (if the client was hipper, it would have been), where the concept of navigation would be meaningless. I strive for as valid and accessible as possible.

    So what good is it to add tags that I don’t need to use all the time? What problem are we solving? I see canned code being handed out instead of taking the time to learn how you can get a lot done just by tossing in some IDs and classes.

    Let’s standardize the vocabulary, sorta how microformats is doing. Its data about data and its ready to go. Build smarter parsers.

    That dataset attribute in HTML5 is about the only thing I’m really excited for.

    Oh, and the argument that new tags clean up divitis is a terrible one; you’ve cured one ailment and injected tagitis. At least a div is a div and when I think its special, I can add an ID to it.

  53. “Eric Fields”:http://eric@ericdfields.com/ asks

    bq. So what good is it to add tags that I don’t need to use all the time? What problem are we solving?

    It’s a good question. 🙂 If you look at the “WHATWG process for adding new features to HTML5”:http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F , you’ll find that contributors are supposed to begin with a user problem not a technical solution. For example, a recent contributor suggested an ‘author’ element for use in citations without explaining what user problem it would solve, and so was told to go back and explain the actual problem. I believe the new structural elements do solve important user problems, but if you disagree, there’s also a “process for removing current features from HTML5”:http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_the_spec.3F .

    Every site doesn’t need to feature a semantic for it to be in common use and benefit from explicit markup: not every site has a table, but I’d assume you wouldn’t suggest replacing table markup with class and ID names? These semantics for the new structural elements are in common use, as the “Google Web Authoring Statistics”:http://code.google.com/webstats/2005-12/classes.html show.

    ‘h’ solves the problem of expressing a seventh-level heading in HTML (I’ve run across this problem once or twice). It also makes it easier to copy and paste code from one place to another (since you don’t have to adjust the heading numbers) or to allow contributors to your site to include headings in posts, comments, or wiki articles without hard-coding particular heading levels.

    One simple use-case for the other new structural elements (‘header’, ‘footer’, ‘nav’, ‘article’, ‘section’, ‘aside’, ‘dialog’) is for user-agents to provide keyboard or verbal shortcuts for moving around the page quickly. For example, marking up your navigation with a ‘nav’ element means that user agents can implement a more reliable “Skip to Content” command (at the moment they can only _guess_ where content begins by looking at link density, looking at visual blocks, or looking for common class and ID names). Rather than remembering what heading level this site uses for article titles, you can simply use the ‘Next Article’ command. Conversely, when you have finished going through the site, you can use a ‘Jump to Navigation’ command to explore the rest of the site. These represent substantial improvements for people with mobility or visual disabilities.

    Another simple use-case is user-agents being able to supply alternate presentation options or users being able to customize their user experience directly. Rather than styling an array of class and ID names, you can style ‘nav’ as a dropdown menu. You can rely on ‘title’ to tell you where you are, hide the main ‘header’ and main ‘footer’, and move the main ‘nav’ to the bottom of the screen to put content first.

    Yet another simple use-case is making it easier to spider content. For example, if you want the articles from a site that doesn’t syndicate, you can simply extract each ‘article’.

  54. “Eric Fields”:http://www.alistapart.com/comments/semanticsinhtml5?page=6#51 suggests instead:

    bq. Let’s standardize the [class and ID] vocabulary, sorta how microformats is doing.

    Depends what you mean by “standardize”. HTML5 initially tried to standardize certain class names such as a ‘copyright’. However, it turned out that sites actually use the class in different ways; microformats tend to rely on opaque ancestor classes like ‘hcard’ or ‘hatom’ to distinguish them from similar class sets. The microformats community said they didn’t require standardization of class names. So predefinition of class names was dropped from the specification.

    I’m all in favour of extensibility via microformats, but the microformats community is a spec-writing not a standards organization. Microformats are never going to be a requirement for writing conforming HTML; they are never going to be taught as an intrinsic part of the HTML standard. If we want a standard encoding of a semantic to be used as widely as possible – if it serves a common, important user need – it must be an HTML element or attribute in the HTML standard.

  55. “Rob Burns”:http://www.alistapart.com/comments/semanticsinhtml5?page=5#49 says:

    bq. For many specialized vocabularies, what’s needed is simply the ability to add specific semantics through the addition of elements, attributes or attribute values which can then be presented with a default stylesheet the spans all media types. So the specialized vocabulary (links, vector graphics, mathematics, user interface) would still be developed in a centralized way. However, the distributed extensibility would take place in a way that made significant re-use of those abstracted vocabularies for other more concrete vocabularies.

    Hmm. Assuming that SVG and MathML are provided with text/html serializations, can you give a concrete example of the distributed extensibility you mean and how it would be more usefully, efficiently, and accessibly implemented using an XML element than a set of HTML ‘class’ and ‘content’/’equivalent’ attributes?

    (Incidentally, I don’t really agree that a ‘datagrid’ is simply another presentation of a list; I think it actually represents an editable dataset; but that’s not crucial to this discussion.)

  56. I wrote:

    bq. “˜h’ solves the problem of expressing a seventh-level heading in HTML (I’ve run across this problem once or twice). It also makes it easier to copy and paste code from one place to another (since you don’t have to adjust the heading numbers) or to allow contributors to your site to include headings in posts, comments, or wiki articles without hard-coding particular heading levels.

    Ahem. Some little birds have just reminded me that there is no ‘h’ element in HTML5 (that’s XHTML2). Instead the heading algorithm has been redefined to allow the combination of ‘section’ and ‘h1’ to solve the problems I mentioned. Sorry for the confusion. See the “draft spec”:http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#headings-and-sections for details.

  57. @41

    “If we lay aside the considerations that HTML5 includes “˜canvas’ and may include a text/html serialization of SVG in the future, and pretend that it also included a “˜content’/’equivalent’ attribute, I don’t see why it would be an order of magnitude harder to implement a language with the same meanings and functionality as SVG in HTML plus CSS plus JS than in (a) HTML plus attributes for different semantic types, or (b) a brand new XML language. I think all would be sort-of possible, but none would be performant (element per pixel anyone?). I think what made SVG practical was user agents implementing the necessary high-performance drawing code; it’s not an example of distributed extensibility.”

    You’re conflating the canvas element and SVG and the two share nothing other than they are graphical, and can be used in web pages.

    And when you say one can emulate SVG with HTML, CSS, and JavaScript, I have to assume you haven’t worked with SVG overmuch. No insult intended, but there is a large difference between a vector markup with support for declarative animation, and a script-based bitmap element. Just turn off JavaScript to see what I mean.

    And when you say it’s not an example of distributed extensibility, again, I’m not sure where you’re coming from. The concept of distributed extensibility has nothing to do with semantics, or graphics for that matter, and everything to do with incorporating a capacity for change without having to modify the underlying parser, and mitigating the effects of naming collisions through the use of some sort of namespace mechanism.

    With XHTML, I can incorporate SVG inline, RDFa, MathML, and whatever other extension I want to incorporate at some future time. Currently I use SVG for design, and RDFa for semantics.

    The browser may process the data, as most do with SVG. Or it may not, as most don’t with RDFa. That’s not important. What is important is that when a new extension comes along that’s formatted in whatever format is valid for browser consumption, it doesn’t have to go to committee. Doesn’t have to be somewhat merged into the underlying data domain of the web page specification. Can be used immediately.

    With this concept, not only is the underlying page markup kept clean, and as simple as possible, we don’t have to wait years in order to make use of the extension. Most browsers don’t do anything with RDFa, but there are Firefox and other extensions that can use it.

    I use XHTML, but it has come with a cost in time, because it’s unforgiving. I’m willing to make the time, but a lot of people are not. Unfortunately some browsers like Firefox take the concept of returning an XML error literally, and provide the most awful error page in the world. Others, though, like Opera and Safari, return errors that are much more helpful. That’s why many of us were hoping that we could have the best of both worlds–the forgiveness of HTML, with the extensibility of XHTML.

    (And it’s hard to write all of this in dinky comment box, so apologies in advance for typos.)

  58. To answer Bruce’s question way back in comment #14:

    Microformats are used in many more places than you think. ALA uses the copyright Microformat as part of its design.

    Expect to see more usage of the hAtom/hfeed Microformats as they are being used in IE8 to accomplish their new Web Slices feature.

    I might recommend the Tails Export extension for Firefox to alert you what Microformats are present on a page.

  59. bq. And when you say it’s not an example of distributed extensibility, again, I’m not sure where you’re coming from.

    If all you’re saying is that vector graphics markup is a useful feature to have in any web technology stack, then I entirely agree as do the people who want a text/html serialization of SVG to be included in HTML5.

    I was trying to use SVG as an example of the practical limitations of distributed extensibility. Just to recap, my argument in a nutshell is that:

    1. Neither HTML nor XML (plus JS plus CSS plus ARIA) yet give you distributed extensibility that provides meaning or functionality to users of user agents not specifically programmed with an interface for those meanings or functions, except for such meanings and functions as can be derived additively.

    2. Nobody’s identified any practical advantages – from a pure distributed extensibility perspective – that XML plus JS plus CSS plus ARIA has over HTML plus JS plus CSS plus ARIA.

    SVG is an example of a technology that might have been possible, but would not have been very practical, for developer communities beyond the standards organizations and consuming software vendors to have designed and implemented in webpages in popular browsers using HTML, JS, and CSS, or using XML, JS, and CSS. You’ve pointed to just one of the problems that would have entailed: dependence on publisher JS.

    Today, SVG has already been implemented – by browsers and plugins. Perhaps accessible 3D environments might be a more current example of a technology which are not very practical in an XML language without implementation by consuming software.

    bq. With XHTML, I can incorporate SVG inline, RDFa, MathML, and whatever other extension I want to incorporate at some future time. Currently I use SVG for design, and RDFa for semantics.

    bq. The browser may process the data, as most do with SVG. Or it may not, as most don’t with RDFa. That’s not important. What is important is that when a new extension comes along that’s formatted in whatever format is valid for browser consumption, it doesn’t have to go to committee.

    bq. “¦ That’s why many of us were hoping that we could have the best of both worlds—the forgiveness of HTML, with the extensibility of XHTML.

    But you haven’t established that text/html is less extensible than XHTML! You’ve just pointed out that some XML languages have some functionality (vector graphics and mathematical typesetting) implemented in browsers that text/html doesn’t.

    XML formats don’t have vector graphics or mathematical typesetting abilities _because_ XML is better for distributed extensibility, but because W3C only defined XML serializations of MathML and SVG. W3C once drafted “mathematical extensions for text/html”:http://www.w3.org/MarkUp/html3/maths.html and Microsoft originally proposed and implemented a “vector graphics language using XML data islands within text/html”:http://www.w3.org/TR/NOTE-VML.html . If the text/html serialization of HTML5 included SVG and MathML, as some people want, that difference would disappear. Note that the current draft includes “embedded MathML”:http://www.whatwg.org/specs/web-apps/current-work/#mathml and “embedded SVG”:http://www.whatwg.org/specs/web-apps/current-work/#svg .

    Depending on your point of view, draconian error handling of XML is either a major benefit (‘Yay it’s stricter’) or a major cost (‘but now my site is broke’). If you think, it’s a major cost, you might be interested in the “XML5 project”:http://code.google.com/p/xml5/ .

    text/html parsing will likely always be more complicated than XML parsing, although by the time HTML5 is finished it will hopefully be better specified. But this complication is something you don’t need to worry about if all you’re doing is adding class names and hidden values.

    Formats serialized via HTML5’s existing extension points plus ‘content’/’equivalent’ wouldn’t _have_ to “go to committee” either.

    My issue is not about whether all these new formats are “valid”; but whether they actually work for end-users. It seems to me they run a serious risk of making the accessibility problems with machine data in microformats look like small potatoes.

  60. bq. Hmm. Assuming that SVG and MathML are provided with text/html serializations, can you give a concrete example of the distributed extensibility you mean and how it would be more usefully, efficiently, and accessibly implemented using an XML element than a set of HTML “˜class’ and “˜content’/’equivalent’ attributes?

    I’m glad you asked. I mean to provide some examples in the earlier post and forgot. What I’m thinking of with distributed extensibility is various specialized disciplines providing extended semantics on top of HTML. For example a society of poets or musicians or astrophysicists might add new elements, new attributes and new attribute values to express the semantics particular to their respective specialties. In addition, the society of Einsteinian astrophysicists might develop a vocabulary of elements, attributes and attribute values that uses similar or identical names to the quantum physicists. Any of these vocabularies can make use of SVG, MathML, XLink, XInclude, XForms and other behaviors provided through other vocabularies.

    The idea then is that we not only have a namespacing mechanism (which is very cumbersome when relying on class names), but that we have a rich vocabulary of abstracted behaviors for namespaced vocabularies to draw upon. That means any arbitrary vocabulary can include vector graphics, hyperlink activation, frames / split views, mathematics, embedded content, and user interface widgets. Moreover, with a better extensibility mechanism new extended abstracted behaviors could be added to the host language without spending years or decades waiting for a new HTML recommendation. None of this is possible with the HTML5 approach.

    However, with a namespace mechanism (and one has already been implemented in IE for text/html), and abstracted and namedspaced behaviors, new semantics can be added to the host vocabulary (and the host serialization) while using ARIA and CSS to provide any accessibility and presentational mappings. Again, this cannot be accomplished by simply adding MathML and SVG to text/html as the only two anointed behaviors in HTML.

    bq. (Incidentally, I don’t really agree that a “˜datagrid’ is simply another presentation of a list; I think it actually represents an editable dataset; but that’s not crucial to this discussion.)

    Certainly datagrid is editable, but I don’t think we should start adding separate elements for editable and read-only semantics for lists or anything else. We already have an attribute to change any element to an editable element. and if lists have a need to fine-tune that editing it would be better handled through an attribute (another excellent example of the point this article makes). Another example is OUTPUT which is borrowed from XForms and XHTML2. This is really a read-only version of the INPUT element that has a different presentation in its read only state. Is there really a need to add more elements to the vocabulary for that subtle distinction? I think not. A read-only attribute could work in that case (perhaps on other UI controls too). For example a METER and PROGRESS element are two more examples already included in the article where the UA provides a graphical presentation of a proportion or fraction. From a device independent point of view, these elements are the same thing. This functionality really belongs at the presentation level in CSS or other such specifications.

    With regard to Eric Fields’ remarks in comment @50/51, we should really be working towards the goal where Eric does all of his front-end work in CSS (supplemented by SVG, bitmap graphic editing and an occasional XSL). There may be some need to reorder the backend elements though this could be done using XSLT as another front-end tool. Eric doesn’t want to take the time to understand the semantics of the back-end vocabulary and that’s fine. It is an excellent division of labor. However, its important to understand that using a DIV and giving it an ID does not substitute for the diverse device-independent, accessible and abstracted capabilities of the specialized elements and attributes. But as a front-end author, Eric shouldn’t even need to deal with those issues.

  61. bq. Depending on your point of view, draconian error handling of XML is either a major benefit (“˜Yay it’s stricter’) or a major cost (“˜but now my site is broke’). If you think, it’s a major cost, you might be interested in the XML5 project .

    I don’t really think that’s the fair way to put this. The major benefit of XML error-handling is that errors are discovered immediately (a relief) rather than after deployment (embarrassing). Also, any error-free element can be made a child of any other error-free element without creating any new errors (at least well-fomedness errors which is what this discussion is referring to).

  62. “Rob Burns”:http://www.alistapart.com/comments/semanticsinhtml5?page=6#60 writes:

    bq. The idea then is that we not only have a namespacing mechanism (which is very cumbersome when relying on class names)

    The merits of XML namespaces are debatable; I don’t have a strong opinion about them. Personally, I don’t see what’s so bad about:

    swiss-society-of-astrophysics-and-astronomy:particle-type

    if (say) the Swiss society really cannot agree on a common vocabulary with the American Astronomical Society, who naturally prefer

    american-astronomical-society:wave-variety

    – but I don’t want to debate the aesthetics, only the technical potential. The key point here is that you agree that it is _possible_ to ‘namespace’ with class names alone, just as JS libraries manage with simple formulations like ‘YAHOO.util.Dom’ to ‘namespace’ variables and functionality, even if you feel it is “cumbersome”.

    bq. “¦ but that we have a rich vocabulary of abstracted behaviors for namespaced vocabularies to draw upon.

    This seems fundamentally the same as Shelley Powers’s argument in favour of distributed extensibility using XML: you want to make use of functionality only available in XML languages. However, if you can make use of the same functionality (vector graphics, mathematics, sophisticated forms) in text/html, then that difference disappears – especially if when this functionality finally appears as native features in IE (the browser most people use) they are available in text/html.

    bq. Moreover, with a better extensibility mechanism new extended abstracted behaviors could be added to the host language without spending years or decades waiting for a new HTML recommendation.

    Who is going to specify these “new extended abstracted behaviors”? Who is going to implement them? Who is going to ensure they safeguard security and accessibility? How are pages using them going to degrade gracefully in user agents that have not implemented them? Why should “a new HTML recommendation” take significantly longer to produce than specifications for “new extended abstracted behaviors”? In the meantime, why couldn’t these “new extended abstracted behaviors” be attached using the HTML5 text/html extensibility mechanisms plus ‘content’/’equivalent’, rather than attached to XML elements?

  63. bq. This seems fundamentally the same as Shelley Powers’s argument in favour of distributed extensibility using XML: you want to make use of functionality only available in XML languages. However, if you can make use of the same functionality (vector graphics, mathematics, sophisticated forms) in text/html, then that difference disappears — especially if when this functionality finally appears as native features in IE (the browser most people use) they are available in text/html.

    That is certainly not what I am saying. I’m not sure about Shelley Powers. I want to see the same (or similar) namespace extensibility mechanism brought to text/html. It is the WhatWG that opposes this.

    Yes, I do agree that class names can express new semantics. However, why are we sitting around trying to justify the increasing cumbersome process (using class names and negotiating potential conflicts for authors who want to draw on two different vocabularies). We already have an XML namespace solution that IE has largely implemented for text/html. And as you say this it he browser used by the majority of users. So why aren’t we inviting the other browsers makers to implement XML namespaces in text/html and then authors can use them whichever serialization they choose to use. So what is gained by using class names instead of the much more elegant and much more flexible solution of namespaces (XML or otherwise).

    Incidentally this again speaks to the predatory monopolistic practices I spoke about before. Why would anyone in their right mind be quibbling over serializations? Who cares whether it is XML or text/html? Well the reason these issues are up for quibbling is that some predatory monopolies want to make it difficult to develop these standard format which they do not own (which also partly explains why it takes decades by the HTML5 editor’s own estimation to develop an incrementally updated standard ).

    bq. Who is going to specify these “new extended abstracted behaviors”?? Who is going to implement them? Who is going to ensure they safeguard security and accessibility? How are pages using them going to degrade gracefully in user agents that have not implemented them? Why should “a new HTML recommendation”? take significantly longer to produce than specifications for “new extended abstracted behaviors”?? In the meantime, why couldn’t these “new extended abstracted behaviors”? be attached using the HTML5 text/html extensibility mechanisms plus “˜content’/’equivalent’, rather than attached to XML elements?

    The idea behind distributed extensibility is that any community of authors could implement a new vocabulary. Any author can then opt to join in that community and make use of that vocabulary and mix it with other vocabularies without any concern for conflicts. By improving text/html paring, we will generally not have the same graceful degradation problems we have today (where element’s will not even parse correctly). I’m not entering into a debate over which serialization an author should use. However, XML namespaces is now widely implemented (in every major browser except that IE implemented it for the HTML namespace only in the text/html serialization and all of the other browsers support the HTML namespace only in the XML serialization). We need to make it available in either (or any) serialization and allow author communities to make use of it. Authors and authoring communities would still have the option to use class names and other mechanisms, but my guess that given the choice and widespread interoperability, they would choose to use XML or XML-like namespaces.

    As for the abstracted vocabularies, my sense is that most of what we need has already been provided by the W3C. We just need broader implementation of those recommendations. I think more could be done with CSS so that we reach the goal I suggested before where front end work is done almost entirely with CSS, SVG, and bitmap images and semantics are properly handled by the rest of the recommendations (HTML needs to be rounded out a bit for semantics too). So this means: 1) incrementally better CSS, 2) incrementally better HTML, and 3) better text/html parsing algorithms. With that much of these debates over serializations or extensibility mechanisms, etc. would all be moot (though we’d undoubtedly have something else to discuss).

  64. bq. Yes, I do agree that class names can express new semantics. However, why are we sitting around trying to justify the increasing cumbersome process (using class names and negotiating potential conflicts for authors who want to draw on two different vocabularies).

    I think you can solve most of the vocabulary-mixing problem without adding new features to HTML5 by using prefixes, just like JS libraries do, and sharing information about what class names you are using with the rest of the web community.

    What I wanted to verify is that new features are not absolutely required for distributed extensibility of vocabulary, and from what you’re saying it seems they aren’t.

    It’s perfectly reasonable to go on from that conclusion (as you do) to argue for XML-namespaces-in-HTML, but on the basis of trying to automate vocabulary isolation when vocabularies are mixed, rather than on the basis of actually enabling distributed extensibility of vocabulary.

    I don’t have that much enthusiasm for that argument, partly because I’m not sure XML-namespaces-in-HTML are the simplest way to implement such ‘namespacing’ and partly because I think other issues are more urgent, like the omission of a generic machine-data attribute from HTML5.

    bq. We already have an XML namespace solution that IE has largely implemented for text/html. And as you say this it he browser used by the majority of users. So why aren’t we inviting the other browsers makers to implement XML namespaces in text/html and then authors can use them whichever serialization they choose to use. So what is gained by using class names instead of the much more elegant and much more flexible solution of namespaces (XML or otherwise).

    Isn’t one gain that class names can be parsed by, styled, and scripted in all current popular user agents, whereas XML-namespaces-in-HTML can only be parsed by one very popular current user agent? (The article proposed HTML5 should add features using attributes rather than elements for precisely this sort of backwards compatibility reasoning.)

    bq. As for the abstracted vocabularies, my sense is that most of what we need has already been provided by the W3C.

    But if we really don’t need to add new behaviors to the XML behavior set, and implementing vector graphics, mathematical typesetting, and more powerful forms in text/html removes the functionality gap between text/html and the XML world, then the subsequent speed of adding “new extended abstracted behaviors “¦ to the host language” isn’t an important consideration when asking what we need to enable distributed extensibility – since all we really want to extend is vocabulary without changing interface.

  65. Firstly, thanks for the thoughtful, detailed responses, and apologies for being so slow to participate in the conversation. It’s incredibly gratifying after having put considerable effort into a piece to have such an intelligent and in depth conversation emerge from it. Aboveall the goal of the piece was not to prove the point I was making and, but rather start an important conversation that is not taking place and which I think should be.

    Some responses to the intelligent various thoughts, observations and so on.

    To Jeremy Keith – thanks for the JS workaround. I became aware of that toward the end of the process of putting the article together. I think the general position of my argument holds regardless – having to use JavaScript in this way is not a general solution to the problem.

    Here to me is the key problem (and I clearly didn’t articulate this nearly well enough in the article, as it is the crux of my focus on the importance of backwards compatibility).

    Technologies flourish when adopted by developers, and die when not. If you look at the “chasm” model of technology adoption, often technologies appear to take off like wildfire – among early adopters. Where technologies really struggle is with their adoption by mainstream users – and the way in which mainstream adopters decide whether to adopt a technology is very different from the early adopters – early adopters are experimenters, they like to try cool stuff, see what works, and so on. Mainstream adopters simply aren’t like that. They are far more pragmatic. The speed and even the extent to which a technology is taken up by by early adopters doesn’t correlate with it’s “crossing the chasm” to mainstream adoption.
    With web technologies (and here CSS is a very interesting and relevant prior example) a key determinant of their adoption among mainstream, pragmatic developers is that they work ubiquitously. After all, even as of late 2008, over 25% of early adopter profile web developers stated clearly that “Pages should look as near to identical as possible across browsers” – despite a decade or more of advocating for adaptive designs. Based on the experience of the slow adoption of CSS in the 1990s – time and time and time again, among developers, educators, writers, you would hear the phrase “but CSS doesn’t work”. This in my opinion undoubtedly held back the uptake of even the CSS that worked very well by years – and given ongoing prevalence of the use the font element [1], coupled with conversations I’ve had with professional developers in the last year or two, to this day, this belief is not entirely eradicated, and continues to have its effect.

    Now, given CSS had effectively no competition (a good deal of what CSS provided was not possible with presentational HTML), whereas HTML5 does (it’s called HTML/XHTML) – if there are perceived or actual backwards compatibility issues for even the most simple aspects of the language (new elements like section) – I’d predict the chances of its widespread adoption happening anytime soon is pretty much non-existent. You only have to look to XHTML2 for a very near parallel example.

    That there’s a JavaScript workaround that extremely well informed and skilled web developers might be aware of is simply not going to address that issue. I foresee everyday web developers trying to use the simplest aspects of HTML5, such as using the section element (which introduces the problem of a semantic mismatch between the meaning of H1 in HTML5 and in older versions of HTML, for what it is worth), try styling it, see that it doesn’t work in IE7, and then simply abandon any attempt to get up to speed with HTML5, as, a la CSS, “it doesn’t work”.

    Quite a few of you suggested that we have the solution – XHTML with DTDs, or XML. The problem is that these have been around for coming on a decade, and are little if at all adopted by mainstream web developers (in fact, one of the reasons I focussed so specifically on backwards compatibility in HTML5 is that the lack of compatibility for most of the last 10 years with most browsers in common use is probably the single most important reason for the failure of these solutions to take off. Well, that and their complexity, in comparison with good old HTML.)

    But keep in mind that the focus of this article is HTML5, and I’ve taken it as a given that the momentum for HTML5 to be the next major iteration of HTML more or less guarantees that will be the case. If nothing else, if it doesn’t make it, we will have wasted years and an enormous amount of energy and resources and have still not addressed significant shortcomings in HTML. So, my concern is to address what I consider to be a serious shortcoming in HTML5’s approach to an important aspect of the language – how it supports semantic markup.

    A number of folks took the fsck IE6 approach ;-), or argued that it’s rapidly diminishing in use.
    My argument is that we simply can’t ignore IE6 and backwards compatibility more generally, because as we’ve seen with many other very good technologies (SVG for instance), they simply won’t be adopted by the majority of developers because of that lack of widespread compatibility.
    If we are concerned about the adoption of HTML5, then we really need to ensure that there are as few impediments to its adoption as possible. If the meme of HTML5 is not compatible with IE6″ (which will soon become simply “IE” then “HTML5 is not supported in any browsers” takes root, then it can take years (as CSS advocates will attest) for those memes to be eradicated.

    Jeremy Jarratt puts it most strongly

    Does anyone seriously believe that we can get by just on minor modifications to the current HTML spec for the next decade?? Of course not! Sooner or later, we’re going to wish we had a continuous supply of new elements, where such things make sense, universally speaking.

    While in many ways a very attractive idea, I think XML is an object lesson in exactly why this is hard if not impossible. XML was in many ways the way to start afresh. We’ve seen how well that’s worked out (at least when it comes to the web).
    If we do wish we had “a continuous supply of new elements, where such things make sense”, then the current HTML5 proposal doesn’t provide that at all.

    Regarding RDFa, it definitely should have got a mention. As I developed these ideas over the last couple of years, and the article (which has been in gestation for just about 12 months now), RDFa was coming together. I see the proposal that I’ve put together as being able to work in conjunction with RDFa, but more akin to providing a better framework within which existing widespread developer practices of using HTML class and id attributes to add pseudo-semantics to their markup, exemplified by microformats.
    But RDFa is a quite radical departure from this existing common semantic practice. As such there’s no great guarantee that it will catch on, and in many cases, will be overkill for the purposes that most developers markup their content “semantically”.

    data attribute, content attribute

    A number of folks raised the HTML5 data attribute – but this is simply a bucket for applications to store their own data in. It’s expressly not for generalized uses –

    “User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values”

    Thanks for the reference to the content attribute Mark Birbeck. As with role, I don’t see why it wouldn’t make sense to adopt that as these existing attributes from XHTML2.

    As to why class, meta, id and rel alone don’t suffice – there’s a number of arguments.

    Firstly, I’ve tried to make the case that we’ve simply pushed these rudimentary semantic extensibility features of HTML past breaking point – the BBC microformats saga is pretty strong evidence of this.
    Class is simply a bucket for strings which can be used for “general processing” – which can mean just about anything. id is essentially a bucket for a page level GUID – any semantics we layer on top of these attributes is really by tenuous convention. In short, they haven’t worked. In fact they weren’t really designed for semantics in the way they are commonly used now at all.

    A number of respondents asked (at times as advocatus diaboli) whether the proposal wasn’t a “solution in search of a problem?”. I always think that’s a very good question to ask.
    I think the fact that so many developers are using class and id as a mechanism for adding psuedo semantics to their documents that you’d really have to call it a standard practice among professional web developers, and the the considerable success of microformats despite the technical limitations of HTML, and even the addition of new semantic elements to HTML5! are indicators of the need for the semantics of HTML to be further enriched.

    Craig Sharkey raised the issue of semantic libraries analogous to JS libraries – and it’s a good question as to why they haven’t really occurred to date (you could argue that this is to some extent what microformats are). I’d argue that the lack of any real mechanism for creating such libraries, other than simply using class and id, is one reason why we’ve yet to see the widespread development of such things.

    Thanks again for the excellent conversation, and I do hope that it might lead to the reconsideration of aspects of HTML5.

    [1] http://dev.opera.com/articles/view/mama-key-findings/

  66. bq. As to why class, meta, id and rel alone don’t suffice — there’s a number of arguments.

    bq. Firstly, I’ve tried to make the case that we’ve simply pushed these rudimentary semantic extensibility features of HTML past breaking point — the BBC microformats saga is pretty strong evidence of this. Class is simply a bucket for strings which can be used for “general processing”? — which can mean just about anything. id is essentially a bucket for a page level GUID – any semantics we layer on top of these attributes is really by tenuous convention. In short, they haven’t worked. In fact they weren’t really designed for semantics in the way they are commonly used now at all.

    There are two arguments here.

    1. The BBC dropping microformats is evidence that existing extension mechanisms are insufficient. This is true, but “the BBC were very clear that the only reason to drop microformats was their use of the ‘title’ attribute for human unfriendly data”:http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml ; a problem solvable with a ‘content’/’equivalent’ attribute. Additional attributes for different semantic modes doesn’t help towards solving this problem.

    2. ‘class’ can be used for things other than semantic labeling. This is true, but this isn’t evidence that it doesn’t work for semantic labeling. That’s like saying JS can be used for form validation and therefore doesn’t work for dropdown menus. I’d say that microformats are actually strong evidence that ‘class’ works reasonably well for semantic labeling. I guess the underlying argument here is actually that a multipurpose attribute increases the chance of naming collisions? But introducing further attributes for different semantic modes would only reduce the chance of naming collisions, and they wouldn’t do so more than defensive class naming practice (e.g. ‘rhetoric-irony’ rather than ‘irony’). To actually prevent naming collisions you need a system like XML namespaces or a central registry of names.

  67. Part of the core of the problem is that we have become so enured to hacks to fix things, that it has become almost legitimate to hijack elements of markup to do arbitrary things.

    The BBC decision lays bare a clear example; its a collision between two (ab)uses of the same attribute; neither of which is actually the intended use.

    This is why I consider HTML5 to be a mistake; xhtml was a step forward. It has issues; why aren’t we fixing them instead of taking 2 steps backward?

  68. bq. With Google now redirecting IE6 users to download Firefox or Chrome, I predict that IE6 will soon disappear.
    I very much doubt it. A high proportion of IE6 users have stuck with it because they can’t upgrade to IE7 – because they are on a corporate network and/or are using an older version of Windows. As Chrome has the same system requirements as IE7, the majority of people using IE6 will be unable to install it.

    Firefox has been around and highly publicised for years – and can be run on older versions of Windows. Anyone who is using IE6 on their own computer, and has not chosen to install Firefox (or upgrade to IE7, if on XP), is unlikely to install Chrome.

  69. Pants, that messed up the formatting a bit. Let’s try again.

    bq. With Google now redirecting IE6 users to download Firefox or Chrome, I predict that IE6 will soon disappear.

    I very much doubt it. A high proportion of IE6 users have stuck with it because they can’t upgrade to IE7 – because they are on a corporate network and/or are using an older version of Windows. As Chrome has the same system requirements as IE7, the majority of people using IE6 will be unable to install it.

    Firefox has been around and highly publicised for years — and can be run on older versions of Windows. Anyone who is using IE6 on their own computer, and has not chosen to install Firefox (or upgrade to IE7, if on XP), is unlikely to install Chrome.

  70. @65

    “My argument is that we simply can’t ignore IE6 and backwards compatibility more generally, because as we’ve seen with many other very good technologies (SVG for instance), they simply won’t be adopted by the majority of developers because of that lack of widespread compatibility.”

    I don’t know how to say this politely, but this is pure bunk. Google has already taken the first step to eradicate IE6, and if others would be as equally brave, we might actually finally get rid of this albatross.

    Perhaps instead of a new specification, we need new attitudes, at least in the web development/design community. Where are the risk takers? The people who used to push and actively promote the best, rather than tenderly support the absolute worst of the web?

    All I can say is bunk. If we all, actively worked to finally put this old piece of “refuse” to its long, overdue sleep, we could eliminate it as a problem in less than a year.

    Instead, we play it safe. We tippy toe. We clasp our hands to our breasts and wash and re-wash our fingers over and over again, in a tizzy of anxiety, as we murmur, in mortified terms, “Oh, we can’t ignore IE6.”

    Yes, we can. Maybe change needs to find a home in places other than just politics.

    Now is exactly when we can force this absolutely essential change. Corporations have other concerns than browser usage, and the people you’re worried about using IE6 are being laid off.

    IE7 not supported in older Windows versions? Well, guess what — Firefox and Opera work on older operating systems. Corporations afraid to change? Oh good lord, no wonder they’re all failing. IE6 is, currently, one of the most insecure browsers in use today.

    Best of all from a change perspective, minimalist design is very hip right now. So, let’s provide a minimalist design for the IE users, and use the nifty CSS3 tricks and SVG for the rest. Then the few IE6 corporate users still employed will still be able to access your site. And, if they want to get the best effect, they can access it, again, when they get home, where they’re using a decent browser.

    But what you’re saying is most designers won’t even take the chance. Wow, must be safe to be them.

  71. @65

    “My argument is that we simply can’t ignore IE6 and backwards compatibility more generally, because as we’ve seen with many other very good technologies (SVG for instance), they simply won’t be adopted by the majority of developers because of that lack of widespread compatibility.”

    I don’t know how to say this politely, but this is pure bunk. Google has already taken the first step to eradicate IE6, and if others would be as equally brave, we might actually finally get rid of this albatross.

    Perhaps instead of a new specification, we need new attitudes, at least in the web development/design community. Where are the risk takers? The people who used to push and actively promote the best, rather than tenderly support the absolute worst of the web?

    All I can say is bunk. If we all, actively worked to finally put this old piece of “refuse” to its long, overdue sleep, we could eliminate it as a problem in less than a year.

    Instead, we play it safe. We tippy toe. We clasp our hands to our breasts and wash and re-wash our fingers over and over again, in a tizzy of anxiety, as we murmur, in mortified terms, “Oh, we can’t ignore IE6.”

    Yes, we can. Maybe change needs to find a home in places other than just politics.

    Now is exactly when we can force this absolutely essential change. Corporations have other concerns than browser usage, and the people you’re worried about using IE6 are being laid off.

    IE7 not supported in older Windows versions? Well, guess what — Firefox and Opera work on older operating systems. Corporations afraid to change? Oh good lord, no wonder they’re all failing. IE6 is, currently, one of the most insecure browsers in use today.

    Best of all from a change perspective, minimalist design is very hip right now. So, let’s provide a minimalist design for the IE users, and use the nifty CSS3 tricks and SVG for the rest. Then the few IE6 corporate users still employed will still be able to access your site. And, if they want to get the best effect, they can access it, again, when they get home, where they’re using a decent browser.

    But what you’re saying is most designers won’t even take the chance. Wow, must be safe to be them.

  72. bq. Perhaps instead of a new specification, we need new attitudes, at least in the web development/design community. Where are the risk takers? The people who used to push and actively promote the best, rather than tenderly support the absolute worst of the web?

    Or maybe we need some hardheaded cost/benefit analysis to establish the “best”, by thinking about the effects of our technical decisions on users, customers, and friends.

    It’s one thing to adopt practices that significantly improve the user experience of some users without significantly impairing the user experience of any large group of users.

    It’s another thing to adopt practices that significantly impair the user experience of a large group of users, especially if there are other ways to achieve benefits for the smaller group of users.

    For example, if developers can encode roughly the same semantics as ‘header’, ‘aside’, ‘footer’, and ‘section’ with ARIA attributes that might improve the experience for the same small group of users without breaking their layout in the most widely used browsers with JS disabled, then maybe it’s rational to use the ARIA attributes instead of the new elements?

    So what if we have to write ‘

    ‘ instead of ‘

    ‘? Is the later better language design? Absolutely. Is it worth the cost to end-users? Not necessarily. On its own, is it worth hassling Granny to switch to a “happy” browser? Perhaps not.

  73. I feel that the test of a good article is the extent to which it makes me think. Your article, sir, has me thinking in spades.

    I work for a sizable company, doing front-end web development, so the topic of HTML5, and all the subsequent topics of backwards-compatibility and forward thinking has me pondering what could be on a day-to-day basis. The advances in JavaScript engines lately has me on the edge of my seat, as well as advances in CSS specification implementation in the major browsers.

    Here’s my thought. I feel that the current HTML spec has us backed in a corner. And until we get ourselves out of it, there really isn’t any hope for us. HTML5, while I applaud the addition of new elements, such additions won’t be enough in the end. Backwards compatibility is great, but in my personal opinion, takes a backseat to future possibilities.

    Please understand, this idea is minutes old, but what’s preventing the W3C and browser vendors from implementing an extensible architecture as opposed to mere elements? Elements we have, but the ability to tailor them with custom attributes should be the future. For example, would it make more sense to be able to define custom attributes like “structure” and be able to add it to the div element (or any element for that matter), with the custom definition containing the information necessary to tell the browser how to interpret it?

    Elements should be objects and attributes should be extended objects, to put the idea in perspective. Yes, there will be an initial hump while older browsers died off, but such a solution would eventually pay for itself. No matter what custom attribute we defined, we also enclose the means necessary for the browser to handle the custom definition. HTML would be like any other object-oriented language. Extensible and scalable. We would load attribute definitions like we load JavaScript. Style with CSS would be as simple as your article suggested.

    It’s just an idea and yes, it completely ignores the backwards-compatibility facet of the conversation. But we live in a dynamic world and this seems like the only out from a future circumstance where we’ll still talking about this very same subject.

  74. I’m glad someone is really talking about these new tags. Personally, I was stoked to see

  76. Imagine if HTML had been invented in Shakespeare’s day. Would we still be using tags like < shoppe type="ye oldde" >? Clearly our existing language may change in hundreds of years (or less if texting has anything to do with it.) So there may be a need to update the words used for tags, even if just to improve them. (Personally I have always found < blockquote > ridiculously long, especially when there is < q >. Why not just have < quote > and use an attribute?)

    Also why should HTML be written in English? Why not have African or Arabic tag names? Perhaps localised versions can be created?

    I say keep improving the existing tags and attributes and of course add new things as the web moves forward. Backwards compatibility is simply a matter of browsers converting any changed tags. Anything new, well hey, one day tables were new and browsers had to cope back then. And CSS! Did we refuse to use it because of pre-CSS browsers? No, we all moved forward by downloading new versions of Netscape. This is the way it has been and should be in the future.

    Having said that Zachary’s idea above is good. How about tags that *didn’t* refer to something specific, but the user then applied the relevant attribute? Eg:

    < box use="sidebar" >
    < list use="menu" >
    < box use="header" >
    < text use="paragraph" >
    < text use="quote" >
    < text use="email" >

    It might make reading documents harder, but there’d be no need to battle over the names of the tags. A standard set would suffice for everything. All the browser needs to know is if the tags are block or inline, floated or not and so on. The stylesheet would provide that.

  77. Surely the guys at W3CHTML5WG already have a vision for adding semantics to HTML, don’t they? And it can’t just be adding ad-hock elements every few years, can it? There are already too many solutions in use out there – microformats, rdfa, embedded rdf, xhtml etc – and clearly few people share a single vision for how this is all going to pan out. But more worryingly, we don’t know what the W3C’s vision is, so we have to make up solutions to prompt them into action. I’m looking forward to the day when they get their act together so we can just build really cool things. But I’m not holding my breath.

  78. bq. Google has already taken the first step to eradicate IE6

    How so? I can still use all the aspects of Google that I need to with IE6, including search, maps and email.

  79. Shelley said, “Corporations afraid to change? Oh good lord, no wonder they’re all failing. IE6 is, currently, one of the most insecure browsers in use today.”

    I was a corporate web developer until June last year,and I too hate IE 6. But to blame the econominc downturn and corporate bankruptcies on it feels a little over-exaggerated.

    Now I work for Opera, so have every reason to diss Microsoft, but it’s wrong to ignore IE 6. It’s temptimng to take the “f**k IE 6” approach, but lots of companies have windows 2000 machines as it’s supported until 2010. Will they upgrade those machines to windows XP or Vista now, in a credit crunch, just to look at sexy web sites that don’t support IE 6?

    Lots of people in the developing world use older machines out of economic necessity. Sure, they could install Linux and then Opera or Firefox, but are we really back to the era of requiring users install operating systems and certain browsers for the privilege of viewing our super-special sites?

  80. I was shocked yesterday to find a major university in England has IE6 on its default drive image that all PCs have to have. So that’s hundreds of machines all stuck on an old browser. I feel this may be typical for IT at other campuses too as they are never bang up to date due to security concerns of upgrading. But I thought they’d at least have IE7 on there.

  81. I have to say the difference between IE6 and IE7 seem so miniscule (especially when one considers the 7 years spent in development) that this sub-thread about how horrible IE6 is looks like a marketing ploy for Internet Explorer and Windows sales :-). Probably just the conspiracy theorist in me, but its worth pointing that out for anyone feeling they need to upgrade.

  82. I see html5 as a opportunity to help encourage people to update their browsers. While I agree with the article (semantics & all), and despite the shortcomings of html5, this is a browser-marketers dream to encourage people to upgrade to a browser that supports the full html5 spec. Of course it will take the completion of ie8 (if they fully support the current html5 spec). However what better excuse could you think of to give your visitors incentive to upgrade their browsers then something like “This website utilizes ‘marketing term’ technology. To use the site to its full potential please upgrade your browser”? The whole industry could push this new ‘marketing term’, making it the next Web2.0 if you will…

    Of course the only downside of this is that there isn’t much substance to this, from a user’s point of view (the canvas tag is one of the few tags that will give users an actual reason to upgrade). As developers we get html5, css3, etc. The user gets not a lot. This strategy needs a lot of refinement, but it’s certainly something that could work.

    It will be a bumpy road, but we need to balls up as an industry and not take the chicken shit way out all the time.

  84. I think we should be focusing on getting browsers to work more consistently and getting rid of old browsers like ie6 that have no place in today’s world. Tech moves fast and yet ie6 lingers on. No matter how you try and make things backwards compatible you will always be limited by decaying technology, there is only so far you can go before you have to stop and address the existence of obstacles like old browsers.

    Ignoring them and creating new languages is great but don’t expect not to run into the same problems a few years later.

  85. I understand your concerns of semantic limitations. I have already solved this problem in the language I created, mail markup language. You can download the schema in order to play with it or read the specification for documentation. I solve the problem through the use of the “role” attribute which is compatible with XHTML and HTML 5. Since my language is inherently XML RDF and OWL are expected to use the role attribute for semantic processing.

    Find everything and more about mail markup language at http://mailmarkup.org/

  86. Since the topic keeps getting raised, I have to ask what are the significant differences in standard support between IE6 and IE7. As far as I can tell they are minimal to non-existent. IE8 promises better support such as CSS :before and :after pseudo element support and the associated generated content properties. However, the big expectation for standard support in IE7, after 7 years of development, was that it would add XHTML support and CSS generated content support. Neither materialized. Nor did other features such as SVG or complete Ruby support. So what are the major problems with IE6 compared to IE7 in terms of standard support that posters keep referring to.

  87. The campus I was referring to have sent round an upgrade to IE7! Now everyone is complaining about the toolbar. (One guy thought the Refresh button had disappeared completely.) Still, at least they now have tabs – one big difference between IE6 and IE7. And better CSS and HTML support. And a heap of bug fixes. And you can zoom in graphics not just text (which also cures the long-standing fonts-set-in-pixels-can’t-be-resized problem). So there’s quite a lot of improvements if you ask me.

  88. bq. And better CSS and HTML support.

    This is the part that my question was about. The claims about IE6 being horrible have mostly related to standards support. Yet with all the things I expected to arrive in IE7 (after many years in development) I can’t really think of many things that IE7 improved. On the other hand, the IE8 beta does offer some CSS and HTML improvements, but what does IE7 offer over IE6 in this area?

  89. Sorry in advance for going slightly off topic…

    @71
    “But what you’re saying is most designers won’t even take the chance. Wow, must be safe to be them.”

    I don’t know how to put this politely either, but that’s just arrogant. And Elitist. Most designers are getting paid by clients who have a very real bottom line in TODAY’S reality where IE6 still represents 20% – 25% of the mainstream market. Front line web developers / designers need to deal with IE6. What they don’t need is to take the blame for it’s over-extended shelf life. That’s like blaming the road designer because your aunt’s old K-car still gets her to Walmart every Saturday.

    Yes, of course there needs to be continued progression and risk taking. And there is. And, IE6 really will die a quiet little death one day. In the meantime, it’s not nearly the catastrophic issue some make it out to be.

    @89
    IE6 has multiple display issues with CSS borders, margins, floats, png transparency and more — most of those display issues were corrected in IE7. There’s this thing called google where you can dig up all kinds of clarification 😉

  90. There were a lot of bug fixes and improvements made to IE with version 7. Even simple stuff like adding was welcome. (I personally don’t think generated content, while useful, is an essential addition.)

    The problem with IE7 is that it also introduced *new* bugs. And there were still plenty of unfixed bugs.

    Anyone wanting to know more about the true horror of IE bugs might wish to peruse the following sites:

    “Position Is Everything”:http://www.positioniseverything.net/

    “Browser Bugs Section”:http://www.gtalbot.org/BrowserBugsSection/

  91. I really appreciate your idea about attributes. I don’t think that we need more than one html attribute: “semantic”. Then anyone can define all the semantic classes he needs. Of course we need to define the properties such as “rhetoric”, “structure”, etc… and their values as we have “background-color”, “font-family”, etc… in CSS

    Here an example of HTML and CSE (Cascading SEmantic sheet):

    HTML:
    ….

    An elderly lady
    phoned…

    ….

    CSE:
    ….
    joke_of_the_day{
    rhetoric:ironic;
    structure:aside;
    }
    ….

    Cascading mechanism may also solve the problem of nestled semantic annotations.
    What do you think about it?
    Regards,
    Matteo (matteo.cajani@alice.it)

  92. Is the browser or the structure (HTML) here really the issue. It would seem that the major hangup for new tags and features in HTML is the backward compatibility.

    What blows my mind is that we as a community continue to perpetuate the problem. Get off HTML and develop something new. Maintain a legacy object capable of rendering HTML but move something to a new open standard. Then, make that easy to upgrade.

    Look at “Flash”. When something new comes out what do people do. Upgrade. What do websites say. “Upgrade to the latest”.

    People, once we stop living in the past and decide that we want robust browsers with true rendering capabilities, 3D models and the ability to take advantage of the other 99% of the hardware, only then will we make progress. We use HTML and CSS as a container for the wiz bang we do with flash and javascript. We want more than text from the browser, so lets finally do what it takes to get there.

    We need to develop an open standard that allows for upgrades and force everyone to abide by the upgrade path. If you don’t, then you cant expect to get serviced.

    Just imagine where you OS would be if we still had to support 8 bit executables!

    Remember this before you respond with the “What about the other devices”. Ok, lets talk about that WAP, Mobile CSS, etc. Your argument is what? That they read the standard HTML you code? They don’t. The only standard is that there is not one. We need one and HTML sure is not it.

    Sure, there will be pain, but once the pain is gone you’ll be much happier in a world where you can do more than just place a few lines of text in a document.

  93. I found the article encouraged me to think more about HTML5 than I have so far. And while I sympathise with the author, I’m in agreement with those commenters that this is a solution in search of a problem.

    It is perhaps a little ironic that the article is a critique of HTML5’s inflexibility when, at least as far as I know, HTML5 was proposed as a pragmatic solution to the seemingly intractable solution of “what comes after HTML4”. This form of critique misses the point behind HTML5: HTML5 is not supposed to be semantically extensible. There is XHTML for that. No, HTML5 is the version of HTML that contains those tags that many currently miss. This has important consequences primarily for those developing browsers so that HTML5 support is both robust and fast. Although this means that the semantics must be frozen, it in no way constrains attributes from being extensible. The difference is, however, one of scope: extensible attributes will have an application (website) specific purpose whereas the specified tags will always have the same purpose.

    The supplied use cases illustrate this misunderstanding:
    [quote]While May Day next year really doesn’t make sense, something along the lines of May Day next year would.[/quote]
    Neither of the tags is semantically satisfying particularly when the tag is available.
    1) Ideally the datetime value should be the content of the tag and not an attribute of it. Confusing the two is a common mistake particularly in XML. Of course, being too restrictive here would prevent anyone from incorrectly using the tag and provoking exactly the kind of errors that HTML5 tries to avoid.
    2) How the date is displayed is a matter of presentation and, therefore, something that may be controlled by meta-data: a format attribute or CSS declaration or browser option. This avoids all the problems of localisation like when is 12/1/2009? In the example supplied format=”holiday” or format=”short”

    Making this definition part of the specification allows browsers to handle content intelligently – offer to add the date to a user’s calender or do a search on the date- in a way the suggested “equivalent” simply could not.

    In the same vein we have the new

    Extensibilty here is not the solution; it simply shifts the problem to the namespace.

  94. In comment #94, Charlie Clark says:

    bq. This form of critique misses the point behind HTML5: HTML5 is not supposed to be semantically extensible. There is XHTML for that. No, HTML5 is the version of HTML that contains those tags that many currently miss.

    This comment reflects a confusion repeated in this discussion that ascribes magical properties to either the XML serialization or the traditional text/html serialization of HTML (I can’t tell which one has bee ascribed magical powers, but neither serialization has any).

    HTML5 is basically three things. 1) it is a parsing and serialization specification that attempts to codify the parsing performed by the major browsers with respect to traditional HTML serializations (and perhaps incrementally improve or at least select the best traits of existing browser parsing operations); 2) A specification of browser (and some other UA) behavior with the results a parsed (however parsed) or DOM created document; 3) a specification of a vocabulary of elements and attributes for authoring documents that are ostensibly semantic in nature.

    The topic of discussion here is about #3. It is not about the parsing and serialization of traditional text/html serializations. HTML5 (in the #3 sense) can arise from the traditional serialization, as a solely DOM creation or from an XML serialization (which despite what we are told is not so drastically different with respect to the topic at hand). So I’m not sure why the use XML or use XHTML line keeps arising in this conversation. It has nothing to do with the topic of the conversation.

    Also this is not about confusing whether data belongs in an attribute or in the contents of an element. There is not one right way to do this. The point of RDFa is that one can easily add properly parsed attributes to existing HTML elements (or any SGML or XML or otherwise elements) that add machine readable metadata about the natural language expression as the contents of the element. That means the presentation can be left as is (with the contents of the element appearing) or the UA could replace or augment that presentation with a localizable expression for the date. And whereas the HTML5 attempt to copy RDFa introduces a single purpose date element, RDFa provides a way to add precise machine readable equivalents to an element for any imaginable data type that can be expressed as the contents of an attribute (including anyURI values).

  95. Rob Mech above wrote:

    bq. Get off HTML and develop something new. Maintain a legacy object capable of rendering HTML but move something to a new open standard. Then, make that easy to upgrade.

    bq. Look at “Flash”?…

    bq. People, once we stop living in the past and decide that we want robust browsers with true rendering capabilities, 3D models and the ability to take advantage of the other 99% of the hardware, only then will we make progress.

    I’ve been thinking for years that Flash should be the way forward. It makes perfect sense. A massive market penetration of users, smooth font rendering that can use any font, all the vector goodness you could want, Photoshop-style filters, what’s not to love?

    And I don’t mean full-blown Flash sites with rotating objects. I mean a plain renderer that improves on what the poor browser has to render. And best of all…

    _Identical cross-platform rendering!_

    Think about it. No more broken layouts due to so many different browsers to test in. No more holding back on things that only work in 1 or 2 browsers. No more having to code to the bare minimum because of ancient browsers still in use today.

    Unless something like this happens we will be stuck in browser hell forever.

  98. > custom DTDs (AFAIK) run in quirks mode

    no. afaik.

    > Identical cross-platform rendering! (flash)

    no. afaik. identical only on windows platforms. he have many bugs on linuxes…

  99. We already have a lot of tools that can provide extensible semantics. The whole point of XHTML (even version 1.0) was to allow users to introduce custom namespaces into xhtml documents and then handle them programmatically using scripts, plug-ins or XSLT. Unfortunately, these technologies are now being bullied out of existence by the simplicity-oriented majority who won’t touch them with a ten-foot pole…

    This is a recurring issue in programming. It appears that, for most people, the introduction of a new concept creates a nearly insurmountable psychological barrier. They say things like “I can’t do it. I can’t understand it. It’s complicated. It’s too abstract”. To me, and a few others (like those who invented object-oriented programming and (XML/XHTML/XSLT/XPath/XQuery), ease of use means fewer clicks and less hand-coding, even if it introduces more concepts I have to learn. To “normal” people, ease of use IS simplicity. New concepts lead to an immediate mental block.

    Just take a look at the whole motivation of behind the move to HTML5. The folks who invented the “html serialization” don’t want doctypes, schemas or even a version number. What they’re trying to do is to make “tag soup handling” part of the spec. Also, they explicitly objected to the use of namespaces.

    The original spec even said

    “Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the “HTML5″? variant described above, and is relatively newer and therefore less mature”

    Fortunately, the W3C didn’t take a stand on the issue, and they removed the above paragraph from their version of the spec.

    We have other strict technologies with extensible semantics in mainstream use, which have a strict, clearly defined syntax (e.g. C#). Very few people ever complained about the whole app not compiling if you miss a semicolon because they have tools that pick up the semicolons for them. I grew up on BASIC, Pascal and Delphi, and I also learned C/C++, so I don’t take error messages personally. But as long as relatively people who don’t know how to escape an ampersand continue hand-coding their HTML in notepad, fault tolerance will remain a requirement, even though after accumulating a certain critical number of errors, it makes tracing nearly impossible, and validators become completely useful because there’s an “error” on every line, but the page displayed fine just an hour ago. For instance, in one of the apps I developed at work, I put up an XSLT post-processor with a syntax checker, and a lot of the other developers would swear at it because they had no clue as to how they can make their code output well-formed XML.

    I believe the Web community needs to split. Just like the desktop application world has Visual Basic for simplicity-oriented developers and C# for those who like structure, we need to have two separate stacks, one for tag soup hand-coders who think namespaces are evil, and another one who prefer a stricter syntax. The split can be made on top of the XHTML5 (the XML version of HTML5), with namespaced elements used to define semantics. Those who prefer the tag-soup-friendly version also happen to be the ones who adhere to the KISS principle and, therefore, don’t need extensible semantics anyway. They would rather copy&paste a block of html ten times over than introduce a new concept for a frequently used element. It doesn’t matter if the majority does tag soup as long as there’s enough community support for the “complex and extensible” version to keep it alive.

  100. I think the phrase tag soup should be retired. It’s one thing to talk about parsing it, another to talk about writing it. It’s important to remember that proper HTML is never “tag soup.” It is however, not necessarily XHTML, and if parsed as such, will be “tag soup.” The reverse is not true. This is precisely what pisses off so many XML purists, because it’s a one-way street. No one should ever slight reading the specs and knowing the proper way to code either HTML or XML, but when it comes to parsing the Web, see the recent Opera study, with MAMA, or the Google study that Ian Hickson did, and it’s clear that less than 10% of what we deal with out there is XHTML, much less proper XHTML.

  101. @Aaron Miller
    bq. I think the phrase tag soup should be retired. It’s one thing to talk about parsing it, another to talk about writing it. It’s important to remember that proper HTML is never “tag soup.”? It is however, not necessarily XHTML, and if parsed as such, will be “tag soup.”? The reverse is not true. This is precisely what pisses off so many XML purists, because it’s a one-way street.

    Tag soup gets used in two different ways which you’re confusing in this comment. 1) tag soup sometimes refers to the serialized source content of a document where tags are potentially misnested, content models invented out of thin air and attribute values requiring quotations not quoted: in general vended content not conforming to any specification anywhere. 2) tag soup parsing refers to a parser that is capable of parsing tag soup (a Herculean task).

    When you say that XHTML parsed as text/html will be tag soup you’re confusing these two definitions. The XHTML is certainly not tag soup as it adheres to the XHTML syntax and sometimes even other syntactic requirements on top of that (such as XHTML 1.0 appendix C), so there is no sense in which that content can be considered tag soup. However, if such an XHTML document is vended as text/html it will be parsed by the UA’s tag soup parsing just like any other conforming or non-conforming HTML 2-4.0.1. So in this sense both: not using XHTML; and not vending as applicaiton/xhtml+xml means that the content is parsed by the tag soup parsing processor (just like any other HTML).

    It’s important to keep these two meanings of tag soup separate to understand the conversation.

  102. @Rob, looks like we’re talking about the same distinction. The only difference is that I’m saying the phrase “tag soup” makes it sound anomalous, when in fact from the content side it refers to over 95% of the web, and from the browser (parser) side, it’s SOP. See the Opera MAMA study and Ian Hickson’s Google report if you don’t know what I mean.

  103. This is not directly related to John’s article, but it reminded me of the following problem I’ve been posing in my head for some time: How is that the syntax of HTML or any other machine-readable grammar is constructed using English? More specifically US English? Has anyone ever tried to construct a language, of even a very light grammar, that allows multi-[Human]languages to describe headers, footers, loops, lists etc? I appreciate that many of these machine-language were first composed in the US and thus US-English has become the Lingua-Franca of programming – but this is the 21st century and not everyone on the Planet who wishes to write code knows how to speak/write English never mind to a specific sub-grammar of it.

  106. I agree with all the principal points in the article, i have the same opinion about a preferrable use of attributes; but i think they’re breaking compatibility on purpose, we all agree it is stupid to still have concerns about IE6 in 2009 (and soon ’10). If they break the cordon everybody will be happier. And in fact the big push on HTML5 came from browser makers, and looks to me MS wants to be in the game.
    In the aftermath we will all have a common base to discuss upon.

    Afterall i think some new tags would come in handy.
    For eg i think that for something as ubiquitous as a calendar, there should exist a tag, it would end the debate wich solution is more semantic (table vs list, that oddly relies on the kind of visualization we want to give), it would spare a lot of code and give more artistic freedom to designers that could target a parameter/class with a simple javascript to radically modify the visualization.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA