1 Nice article, and well said

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.

posted at 09:49 am on January 6, 2009 by Matt Wilcox

2 A shiv for IE

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.

posted at 09:55 am on January 6, 2009 by Jeremy Keith

3 The Datetime pattern and the BBC

I wrote a summary of why the BBC dropped the datetime microformat pattern along with some proposed solutions. Unfortunately an agreement was never reached.

Jake.

posted at 10:00 am on January 6, 2009 by Jake Archibald

4 Great Article!

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.

posted at 10:08 am on January 6, 2009 by Nor Sanavongsay

5 XML with Custom DTDs

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.

posted at 10:13 am on January 6, 2009 by Adam Cooper

6 XHTML

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.

posted at 10:25 am on January 6, 2009 by Richard Cotton

7 Untitled

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

posted at 10:26 am on January 6, 2009 by Gareth Adams

8 IE6/IE7 workaround for HTML5 elements

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/

posted at 10:31 am on January 6, 2009 by James P

9 XML and XSL

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.

posted at 10:32 am on January 6, 2009 by Wojtek Soczyński

10 XML

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…?

posted at 10:38 am on January 6, 2009 by Anup Shah