Jaco’s Random Writings

So the big news last week was that xHTML 2.0 is dead and x/HTML 5 dropped <video> and <audio> from the spec. The biggest kicker being the official euthanasia of xHTML 2. In an article by WebMonkey, they point out that xHTML 2 was pretty much in a coma hooked up to life support (feeding tube and all). The W3C (as well as many web developers, myself included) hoped that one day, xHTML 2 would rise from its coma and rule the web. But as time passed, that became a pipe dream.

Here’s a little insight into what exactly x/HTML 5 is (for those who are not in the know). x/HTML 5 is the future of the web. It was started by the WHATWG (Web Hypertext Application Technology Working Group), who are working hand-in-hand with the W3C HTML WG to develop and eventually recommend x/HTML 5 as a standard. Since x/HTML 5 is being built around the current capabilities of browsers, the browser vendors (Microsoft, Apple, Mozilla, Opera) have a heavy say in what goes in and out of the x/HTML 5 spec. For the most part, this is a good thing. But it can also throw a spanner into the process (more on that later). More information on it can be found at the WHATWG FAQ.

The x/HTML 5 spec (in it’s current state) includes some very cool features.

• The <canvas> tag. Using JavaScript, you can draw vector graphics directly to this. In realtime. Pretty much like having Processing right in your browser (and they have an implementation of that as well). Doesn’t get much cooler than that.
• The <dialogue> tag. This is really good for posting those IM/IRC conversations online. That or if you want to publish a script. No more 2-column tables.
• The “data-” attribute. This allows you to add custom semantic mark-up to existing elements. So I could put down <div class="containers" data-content="slides">. The browser will ignore the custom “data-content” attribute I made, but I can filter for it using JavaScript should I want to add any effects to that specific paragraph. So very awesome. Really good for doing unobtrusive JavaScript. More on that later.

The thing is. The x/HTML 5 spec is still very early in development. It will be a long time before it gets finished. However, parts of the spec are pushed out as they are finalized, as opposed to previous HTML specs that were only pushed out once the entire spec was finalized. I foresee some problems with this approach…

Now, among site coders, there are essentially 2 broad groups:

1. Those who like coding in xHTML 1.0 (and some even in xHTML 1.1) and were happy to make the switch from HTML 4.01. They like the strictness of XML and the strong sense of structure.
2. Those who code xHTML 1.0 because they feel like they have to. When the W3C announced that xHTML 1.0 is the future and that HTML 4.01 is pretty much the last we would see of HTML as we know it, many people begrudgingly switched to xHTML 1.0. To them, HTML was a familiar face they had known for many years and they would go back to it if they could.

Now fast forward to the announcement of xHTML 2. The W3C made is clear that xHTML 2 would not be compatible with HTML, never mind xHTML 1.x. WebMonkey points out that this was one of the nails in the inevitable coffin of xHTML 2. Being incompatible with xHTML 1.0 meant that even people who switched to xHTML 1.0 to future proof their sites suddenly found that their were not so future proof in regards to xHTML 2. This pissed a lot of web developers off. Sites would have to be recoded…again. Coding practices would have to be re-evaluated…again. All in all, a painful transition many people were not willing to go through.

Not all was doom and gloom with xHTML 2. There were a lot of feature that had people salivating:

• Being able to add an HREF attribute to any element, not just <a> tags. This would allow a site coder to turn almost any element into a link.
• The “role” attribute would allow coders to add further semantic meaning to their elements. This is primarily useful for screen-readers and when using unobtrusive Javascript (The “title” and “class” attributes are so abused in this area). This would have been one of the first steps to implementing RDFa triples in xHTML (beyond just in the <meta> tags).
• Navigation lists using <nl> instead of the usual <ul>.

These were many things x/HTML 5 simply did not plan on offering. xHTML.com does a pretty good job comparing the good and the bad between the two. But browser developers made it quite clear that HREF is not likely to make it into all elements. Bummer. Guess we’ll just have to make do with wrapping all linked content in <a> tags.

When x/HTML 5 was announced, the idea was that it was going to be the next version of HTML, following HTML 4.01, not xHTML 1.0 (or any of the xHTML 1.x). Many of the second group of web coders were quite happy about this decision, as it meant that they could go back to their old coding practices and the leniency that HTML 4.01 had afforded them. The future is rosy and everyone’s happy. Well. Almost everybody. The first group of coders, the ones who actually like xHTML 1.0, were none too pleased. They didn’t want to give up xHTML, having spent valuable time attaining xHTML 1.0 String standards compliance. With xHTML 2 looking more and more like a living, breathing corpse, these coders dreaded the idea of going back to HTML. In response to this, the WHATWG and W3C announced that there will be an xHTML serialization of HTML 5. All the fun features and whatnot of HTML 5, but in the form of xHTML (completely backwards compatible with xHTML 1.0). The xHTML serialization of HTML 5 is being developed in parallel and reflects all the changes and additions made to HTML 5. It’s because of this that we refer to the spec as x/HTML 5.

Now, this had people scratching their heads. The spec says, “generally speaking, authors are discouraged from trying to use XML on the Web” (Having read the spec, I haven’t found this statement in the current revision). But again, Ian “Hixie” Hickerson said it best in an interview with xHTML.com in regards with XML and the web:

Some people are going to use XML with HTML 5 whatever we do. It’s a simple thing to do — XML is a metalanguage for describing tree structures, HTML 5 is a tree structure, it’s obvious that XML can be used to describe HTML 5. The problem is that if we don’t specify it, then everyone who thinks it is obvious and goes ahead and does it will do it in a slightly different way, and we’ll have an interoperability nightmare. So instead we bite the bullet and define how it must work if people do it.

In short, xHTML is here to stay. Now that people are using it, you can’t just update HTML without including xHTML in the mix. I’m very sure the W3C had some hand in the decision to serialize HTML 5 as xHTML. But that’s just speculation on my part.

Now, one of the more controversial elements being added to x/HTML is <audio> and <video>. These were intended to allow the browser to present embedded audio and video without the need of plugins. The W3C wanted to use Ogg Vorbis (for audio) and Ogg Theora (for video). These codecs are free and open-source, being published under the GPL (Gnu Public License). This meant that they are royalty-free and do not require a license payment to implement (unlike proprietary codecs like h.264 and WMA). The browser vendors pulled out their swords and a bitter battle ensued. Ian “Hixie” Hickerson described it best:

Apple refuses to implement Ogg Theora in Quicktime by default (as used
by Safari), citing lack of hardware support and an uncertain patent
landscape.

Google has implemented H.264 and Ogg Theora in Chrome, but cannot
provide the H.264 codec license to third-party distributors of
Chromium, and have indicated a belief that Ogg Theora’s quality-per-bit
is not yet suitable for the volume handled by YouTube.

Opera refuses to implement H.264, citing the obscene cost of the
relevant patent licenses.

Mozilla refuses to implement H.264, as they would not be able to obtain
a license that covers their downstream distributors.

Microsoft has not commented on their intent to support <video> at all.

It was a mess. This went on for quite some times before the W3C and WHATWG simply decided to drop <video> and <audio>, letting <object> handle the dirty work as it has been doing for years now. Unfortunately, Mozilla Firefox 3.5 has already implemented <audio> and <video>. Oops. These are the dangers one runs into when using an “Implement it as it gets finished” policy.
Edit: As someone was kind enough to point out in the comments, I seemed to have gotten ahead of myself. No, <video> and <audio> are not getting scrapped (at least not now). I seemed to have misread the mailing list post. However, since argument over which codec to use it still a fiery issue among browser vendors, the future of the two tags is a little uncertain (primarily the <video> tag, not so much <audio>).

In all honesty, I think <video> and <audio> are completely unnecessary and redundant. When I write an <object> tag, I have to specify a content-type (ie “video/ogg”, “audio/mp3″). The browser reads that content-type and then selects the appropriate plugin. But if the browser reads and parses the content-type type, why doesn’t it just natively run the media when it recognizes a content-type type that it supports? In fact, why doesn’t it give me an option whether or not I want it handling supported media types (maybe the plugin does a better job at decoding an mp4 movie?). This gets rid of the whole codec debacle, since each browser supports the codecs it wants. Nothing changes on the user side, since the browser will default to a plugin if it doesn’t support the content-type type. Now a common web codec would be nice, and I am all for making Ogg Theora and Ogg Vorbis the standard codecs of the web. Ogg Vorbis has audio quality on par with AAC and WMA (beats the pants off of MP3). The issue with Ogg Theora is that currently, the quality isn’t quite up to par with h.264 and other proprietary video codec. However, it would appear that by tweaking the way it is implemented, they managed to get better quality video out of it (the information in the link is pretty technical, but it gives a nice comparison screenshot). There really aren’t any patent issues, since not only is Ogg Theora open-source under the GPL, but the company that owned the patent to the codec off of which Theora is based released the patent to Xiph.org, which controls the development Ogg Theora and Vorbis.

So for my final word on this matter: while the xHTML 2.0 is dead, many of the members are being moved to the HTML WG, which means they’ll be working on x/HTML 5. So some of the features from xHTML 2 may still get realized in some form or another in x/HTML 5. We already see it with the “data-” attribute, which is pretty much the “role” attribute on steroids. So, x/HTML 5, for the most part, is out of the woods and well on the road to becoming a recognized web standard. However, the road ahead is most definitely not a clear one, as storm clouds are gathering on the horizon. And while x/HTML 5 doesn’t have to worry about competing with xHTML 2, it will find it difficult to escape the legacy xHTML 2 left behind.

Now, I recommend clicking the links I have provided, since they will definitely provide more in depth information on the topics I introduced in this post.

So until my next post, au revoir.