The Vanishing Image: XHTML 2 Migration Issues
July 2, 2003
Mapping a Migration Path
I am not the world's greatest XHTML 2.0 fan. I initially gave up on it completely because of its intentional (and, in some cases, seemingly spiteful) backward incompatibility with XHTML 1. I was convinced that developers would need a migration path in order to adopt it, and there was no such migration path. This series is, in part, my own attempt to see how big a problem this backward incompatibility really is.
Why bother talking about a migration path at all? All the work I have seen so far in the XHTML 2.0 world has been about what it would be like to be there. Which makes sense, since it's not finished yet and the HTML Working Group is still hashing out the details. However, there has been a distressing lack of information about what it will take to get there from where we are now. Even assuming that where we are now is "valid XHTML 1, used properly" (a huge assumption for most sites), there is still no information about how to make the leap from there to XHTML 2.
Members of the HTML Working Group seem totally unconcerned with this. They have indicated publicly (on the www-html mailing list) that they see no need for a migration path from XHTML 1 to XHTML 2. XHTML 2 is not a replacement for XHTML 1, they say. XHTML 2 is only for new documents and applications built from scratch; no one will bother converting existing documents and applications.
However, experience has shown us that there is a natural demand for the latest and greatest, if only out of fear. Developers see "XHTML 2" and mistakenly assume that it is a replacement for "XHTML 1". And they fear that if they only know "XHTML 1", HR departments will soon start rejecting their resumes because they are filtering on "XHTML 2" (which probably is true; I mean, let's face it). Meanwhile, the HTML Working Group has done just about everything it can do to create confusion in the marketplace by giving XHTML 2 the same name as the language it's not replacing, the same MIME type, and the next major version number.
Looking even further ahead, it is important to note that XHTML 2 is the only W3C-approved markup language that is evolving. The HTML Working Group has stated publicly that there will be no XHTML 1.2. Nor will there be an HTML 5 or even an HTML 4.1. The future will be filled with web features that require XHTML 2. (The first of those, XForms, will be the subject of a future article.)
All of which brings us, in a roundabout sort of way, to today's topic:
Although it's been around for years, the
<object> element is
unappreciated and rarely used. It was meant to be an replacement for several other
<applet>, and the non-standard
<object> features multilevel fallbacks; you
are supposed to be able to define multiple choices for a single object (for example,
same image in multiple formats), and browsers are supposed to render the first one
If none of the choices work out, you can fall back on text; not just plain text (like
alt attribute of an
<img>), but full HTML markup.
This will be clearer with an example. Here is an
image, which you could embed in a page with a single
<img id="beagle" src="beagle.jpg" alt="Beagle in a woman's lap" width="152" height="160" />
You could embed the same image using the
<object> element, like
<object id="beagle" type="image/jpeg" data="beagle.jpg" width="152" height="160"> <p><span class="breed">Beagle</span> in a woman's lap</p> </object>
Several things to note here:
<img>element does not specify a MIME type; that is handled by the web server. The
<object>element explicitly states the MIME type of the linked image file.
altattribute of the
<img>element is limited to plain text. The
<object>element achieves the same purpose (a graphic with text fallback), but it can support full HTML markup for the text fallback.
<object>version won't actually work.
Why won't it work? Well, it will work in some browsers. But not in Internet Explorer.
<object> element is a good idea; unfortunately, it came a bit too late
in the game. Before
<object> was officially added to the HTML
specification in 1997, Microsoft had already introduced its own vendor-specific element
Internet Explorer 3.0 as a way of embedding ActiveX controls in web pages: an element
<object> was later standardized, Microsoft retrofitted support for
it, sort of. Except that, to this day, even the latest version of Internet Explorer
<object> elements as ActiveX controls. Which means that if you have
your security settings on "high" (disabling all ActiveX controls), you won't see any
<object> elements, even ones that have nothing to do with ActiveX (like
the above example).
Even if ActiveX in enabled (which it is by default), Internet Explorer renders the above image with a nasty border, and two sets of scroll bars. (demo)
Oh, and remember when I said that you were supposed to be able to nest
<object> elements and let the browser choose between multiple formats
of the same image? Well, that doesn't work in Internet Explorer either; instead of
the first one it understands, it renders all of them.
And this is why you've never heard of the
But no big deal, right? I mean, who cares about
<object> since we'll
XHTML 2 doesn't have an
<img> element. It doesn't have an
<applet> element either. Both have been obsoleted by -- wait for it...
So is there a way to ease the migration to XHTML 2? Is there a way to start using
<object> now instead of
A Partial Solution
Let's be clear: the problem is Internet Explorer. Mozilla (and Mozilla derivatives
Netscape )7 renders
<object> just fine. So does Opera. (Here's that demo again of the picture
of the beagle. Here are some
more tests to check your browser's support for
Explorer has four problems:
- Renders all nested
- Renders visible border by default.
- Renders visible scrollbars by default.
- Doesn't render if ActiveX is disabled.
The first problem can be worked around by simply not nesting
elements. ("Doctor, it hurts when I do this...") But that's a cop out. What if you
want to use fallbacks for different image formats? Then you can use what are called
conditional comments, a Microsoft-specific technology that doesn't conflict with any
standards and doesn't cause any compatibility problems in other browsers. ( more on
Let's say you had two versions of the beagle picture, a JPG and a TIFF. It looks like this:
<object type="image/tiff" data="beagle.tiff" width="152" height="160"> <object type="image/jpeg" data="beagle.jpg" width="152" height="160"> </object> </object>
But in Internet Explorer, this will render both the TIFF and the JPG (that's wrong!), unless we use conditional comments:
<object type="image/tiff" data="beagle.tiff" width="152" height="160"> <!--[if !IE]> <object type="image/jpeg" data="beagle.jpg" width="152" height="160"> </object> <![endif]--> </object>
The trick to tackling the
<object> element is to realize that it acts
<iframe>; that is, it is its own canvas within a canvas. Within
the DOM, an
<object> has its own
body with all its own
properties. So to remove the border, we simply do this in our
beagle.body.style.border = 'none';
beagle is the value of the
id attribute we defined in our
The third problem, the visible scrollbars, can be solved in a similar fashion (demo):
beagle.body.style.margin = '0'; beagle.body.style.padding = '0'; beagle.body.style.overflow = 'hidden';
You're likely to have more than one
<object> per page. Even if you're
a single function that you can just link from each page, without worrying about the
objects or IDs on each page. You can do that with the
Unfortunately, the fourth problem can't be worked around. Internet Explorer incorrectly
<object> elements as ActiveX controls and, therefore, won't
render them if ActiveX is disabled. Depending on the user's security settings, the
simply not appear; worse, they may be prompted with a "Would you like to allow programs
as ActiveX controls to Run?" dialog, which is likely to scare off even the most dedicated
Remember when I said that Internet Explorer was the only browser with
<object> issues? I lied. There are other issues, of varying degrees of
More Dive Into XML Columns
- Mozilla 1.3 doesn't handle the
<object>image the same way as an
<img>image. Right-clicking on it will not show you the usual image properties, or "block images from this server", or any other image-specific functions. I believe this will be fixed in Mozilla 1.4. Opera 7 has a similar problem.
- Opera 7 treats
<object>like inline frames (the
<iframe>element). This means that if the user has intentionally disabled
<iframe>support (say, to block ads, a common use of iframes), they won't see your
- Several browsers, including Opera 7 and the latest final candidate release of Mozilla
1.4, will not display the fallback text within an
<object>if images are disabled.
- On the flip side, if the user has disabled images in Internet Explorer, it will still render your image-in-an-object.
- Screen readers for the blind, such as JAWS, will read the text of an image's
altattribute aloud. However, they do not support reading the fallback text within an
<object>element, thus rendering your objects completely inaccessible.
- I've also seen unconfirmed reports that Internet Explorer doesn't let you position
anything over an
<object>. For example, on an interactive site, you could create a draggable
<div>on top of an
<img>element, but that doesn't work with
Bottom line: using
<object> as a replacement for
<img> is not a safe bet right now. It's possible that by the time XHTML
2 is finalized, and we have working implementations in next-generation browsers, the
generation of browsers will have fixed these quirks. But from here the migration path
XHTML 2 looks a little bumpy.