Anne van Kesteren

XHTML™ 2.0 - New working draft

The W3C has released a new working draft of XHTML 2.0. New things that are added (not completely sure) include:

There is probably more, just read it yourself. This was just a quick 30 minutes scan of me.


  1. Mmm, very interresting. Thanks for laying it out for us.

    I like most of these, but I am still a little worried about hreflang and hreftype being able to have multiple values. This comes back to new languages/types being added all the time and keeping the links updated with that.

    I like the new metainformation module, since I think it is pesky to keep external RDF files updated when you change a document. (Believe me, I tried.) Hopefully you can now dump some of the RDF and include that in the XHTML directly.

    But like Anne stated, this just makes it even more confusing for more people, and I hope it won't backfire on the specification as being too complex. Although, I do believe that more people will adopt this than RDF.

    Posted by Charl van Niekerk at

  2. Very informative. Anne, you are a gem of the standards community. This is the kind of forward looking coverage we need, not to mention we all should be sharing our insights with the W3C before each recommendation is finalized.

    Posted by Gabe at

  3. According to Arve the ACCESS attribute is a replacement for the 'evil by design™' ACCESSKEY attribute.

    Posted by Anne at

  4. Awesome, another spec that will remain ignored for 5 years.

    Posted by Randy Charles Morin at

  5. This is odd:

    Separators: in previous versions of HTML, the hr element was used to separate sections of a text from each other. In retrospect, the name hr (for horizontal rule) was badly chosen, because an hr was neither necessarily horizontal (in vertical text it was vertical), nor necessarily a rule (books often use other typographical methods to represent separators, such as a line of three asterisks, and stylesheets can be used to give you this freedom). In order to emphasize its structuring nature, and to make it clearer that it has no essential directionality, hr has been renamed separator.

    I thought HR was frowned upon because it was a presentational element, giving style to the page. I was surprised to see it make a comeback. I agree with the new name change and what it suggests, but the default styling is the same as HR!

    The default style for this break is a horizontal line in Western languages.

    Despite that, a lot of this new spec seems pretty good. The NL and L tags are a step in the right direction, along with 'src' being allowed on any element. (Though these were already in XHTML 2.)

    Sadly a lot of junk from HTML 4 seems to remain. Tags like 'samp' are surely redundant? (Use 'code'.) And isn't it time to rename 'blockquote'? (Laughable when an inline quote is marked up with just 'q'.)

    What we should have is a whole new improved set of tags, not what looks like HTML Plus.

    Posted by Chris Hester at

  6. SAMP is still useful. I use it sometimes. XHTML 2.0 creates QUOTE, so that shouldn't be a problem ;-).

    I agree that we should have a new set of elements though. But I think you have to look at Web Forms and Web Apps from WHATWG, not at the W3C.

    Posted by Anne at

  7. And isn't it time to rename blockquote? (Laughable when an inline quote is marked up with just q.)

    I would rather like to see q renamed to quote (much clearer). And that was precisely what they did. So no inconsistancy there. :-)

    Posted by Charl van Niekerk at

  8. Sorry for repeating you there Anne, we posted at exactly the same time it seems. :-)

    Posted by Charl van Niekerk at

  9. I still think the whole concept of xhtml2, as it is today, has a problem and that the current spec represents the least innovative new version of the lingua franca of the web the W3C could have done. Just for fun, take a look at the example showing the start of an html instance when an XML schema is declared... In my opinion, this spec should be dropped entirely.

    Posted by Daniel Glazman at

  10. Just to clarify, my view on what ACCESS seems to be stems from a suggestion I posted to the W3C HTML mailing list last year, and should, until someone from within W3C verifies my view, be treated as "educated speculation"

    Posted by Arve at

  11. Perhaps I'm just contrary, but I don't see hr as presentational at all. It demarcates between a before and an after. What it does not do is enclose everything before or everything after, but then again, neither do headings. What's the big deal?

    Posted by Joe Clark at

  12. Anne, If you have comments, I encourage you to send them to the WG ML for it, so they can be filled as an issue.

    Formal issues and error reports on this specification shall be submitted to (archive). It is inappropriate to send discussion email to this address. Public discussion may take place on (archive). To subscribe send an email to with the word subscribe in the subject line.

    Posted by Karl Dubost at

  13. Joe, I think that only the name was a big deal.

    Karl, I will address the issues mentioned in the post on that list, thanks for the pointer.

    Posted by Anne at

  14. Joe: HR is an abbreviation/initialism for Horizontal Rule. While it's use might have been reasonably sane (in the LTR or RTL world at least), it's name isn't.

    Posted by Arve at

  15. I am still a little worried about hreflang and hreftype being able to have multiple values. This comes back to new languages/types being added all the time and keeping the links updated with that.

    I don't think it's necessary to maintain a list of all available versions of a referenced resource with those two attributes. Quite the contrary. Think of the following example.

    There's a map at the URI that is being referenced. uses content negotiation based on the Accept-Language & Accept HTTP-Headers sent by the user agent. Suppose the author of the document referencing said map wants to link to a specific version of the map, say the french-language-version in PDF format. Without the attributes the author can't ensure that the reader following the link to the map will get the exact version he's referring to, because the version sent to the reader would be negotiated between user agent and webserver, so that the reader could quite possibly end up with an SVG-File in english language.

    I really like the concept of those attributes and think your concerns are unfounded

    (Imagine a <hr /> here)

    [Hreftype] can contain a comma-separated list (why not space-separated, for CSS?) [of MIME types]

    From my understanding the difference between a space-separated list and a comma-separated one is that all values of the former apply to the element (take the class attribute, for example) while a comma-separated list states an order of preference (for instance the font-family property in CSS or the face-attribute of the font-element ;) in HTML).

    Still, I think you have a point as there is afaik no suitable selector in CSS to match a comma-separated list.

    Posted by Gerrit at

  16. @Gerrit:

    I think you misunderstood me there. Of course hreflang and hreftype are necessary when linking to documents on your own site. I was actually referring to linking from your site to other sites which you have no control over. But you still need them. :-)

    Posted by Charl van Niekerk at

  17. @Charl

    No, I think you misunderstood me. The two attributes in concern are imo unnecessary when linking to resources on a server under your control (e.g. your site), because, well the server is under your control.

    It's different when linking to resources on other sites, though. For instance <a href="" hreflang="nl" /> could be equivalent to <a href="" /> if the server's using content negotiation.

    The attribute doesn't mean The resource linked to in the href attribiute has the language 'nl' but rather User agent, please request the resource linked to in the href attribute with an Accept-Language: HTTP-Header of 'nl' (Similar, but not identical logic applies to the hreftype-Attribute)

    In my view, they are unnecessary for most links in the future. Thus, you don't "need them". They're still useful for special cases and will be used increasingly as content negotiation will become more widespread.

    You are right with your interpretation of those two attributes designating language and type of the referenced resource according to the HTML4 spec. Not so with XHTML2 where those attributes have an entirely different meaning and are, imho, very useful.

    Posted by Gerrit at

  18. @Gerrit

    Oh ok, sorry I see what you mean now. I didn't actually look at those in the XHTML 2.0 specification. They changed the meaning somewhat of those attributes. Thanks for explaining, very interesting.

    Posted by Charl van Niekerk at