The Lurker

XHTML 2.0 and the object tag

From XHTML 2.0: The Latest Trick:

Object über alles. img and applet are deprecated in favor of a object, which takes on a multivalent role as a kind of catch all, out-of-band media type entity. In other words, object in XHTML 2.0 is rather complex, and I haven't yet sorted out all that it can do. It is clear, however, that people won't be writing the familiar

<img src="/pix/pavonis-mons.gif" alt="Approaching Pavonis Mons By Balloon" />

anymore. In its place, we'll use something like

<object data="/pix/pavonis-mons.gif" type="image/gif">Approaching Pavonis Mons By Balloon</object>

At this point the type attribute seems to be optional, though it will be useful since it will give browsers some typing information with which it might make intelligent decisions about which version of an object it wants to retrieve or display.

In what was is that "rather complex"? In HTML 4 there are four elements (img, applet, iframe, object) which all do the same thing. They have slightly different ways of specifying what they do, and the first three were intended only for certain classes of media, but there's really no advantage to that differentiation.

In Kevin's blog the other day he talked about getting Flash objects into XHTML. The code he and Neville came up with to get it to work was exactly what a naive person who assumed the W3C's specs were an accurate description of what browsers implement would have come up with.

I don't know what they tried before coming up with that "obvious" solution (and I don't mean to diminish what I'm sure was a frustrating effort to find anything that not only worked in one browser but in multiple versions of three browsers on three different operating systems), but have a look at the kind of crap you usually see today in web pages to embed a Flash object:

And that's not all — that code is written by a bit of Javascript which attempts to detect the Flash player, dumping out the alternate HTML if it doesn't find Flash. Then, because that wouldn't work in a browser that wasn't executing the Javascript, the "no Flash" code is repeated in a <noscript> tag.

This isn't something some Frontpage-using hobbyist came up with; it's lifted from Macromedia's own Flash download page.

You would have a tough time convincing me that what Kev and Nev came up with is "rather complex" compared to what web developers are encouraged to use today. In XHTML 2.0 — well, in fact, this should have been possible with existing HTML 4 browsers, so maybe I shouldn't hold my breath — the type attribute lets the browser figure out for itself whether or not it knows how to display the embedded object (so unlike Macromedia's script, which looks in the non-standard navigator object specifically for a plugin called "Shockwave Flash", it allows for alternative implementations), and if it determines that it cannot support it, it will display the child content of the object element. And, in other browsers which don't support object (which, in general, probably don't support plugins anyway), that child content is also displayed, because that's the normal way browsers were designed to deal with unrecognised elements.

Fortunately, most of XHTML 2.0's changes appear to be fairly straightforward, so unlike CSS 1 we probably won't have to wait five years to see a conforming web browser. It is likely that the Mozilla project will be able to implement much of the necessary changes to support XHTML 2.0 using XBL, a language which takes advantage of CSS's selectors to bind code to document elements. And, you never know, Microsoft might actually get around to improving their browser for the first time in a couple of years.

Related topics: Web Mindless Link Propagation