I have belatedly updated my
note on using object tags to display SVG to reflect my
having removed object
tags from the Alleged Tarot because Safari cannot cope with them..
It is a sad accident of history that HTML has five different tags which are used to do the same task: carve out a rectangular section of a web page and display a different document (resource) there (six if you count frame-sets as HTML documents). In each case, there is a foreign resource, and a software component (call it a handler for the sake of giving it a name) must be found that knows how to display it:
| Tag | Resource type | Handler |
|---|---|---|
img |
PNG, JPEG, GIF, and sometimes other binary image formats | built-in |
applet |
Java class file (applet) | Java applet plug-in |
embed |
Any | Plug-in, determined by media-type |
iframe |
HTML (or other document types?) | web browser |
object |
All of the above | Any of the above |
Now, there was no particular reason for applet and
embed to exist; they do the same thing as
img, the only difference being that
img uses handlers compiled in to the web browser
whereas embed uses plug-ins and applet
the Java interpreter (often this is also a plug-in). Using
different element names merely exposes an implementation detail
of that particular implementation. Netscape could have chosen
to extend the img tag to dispatch to handlers based
on the media-type of the referenced resource.
Apart from anything else, it would have avoided the embarrassing
period when some web sites used embed to render
PNGs and others
used img, depending on the author’s
browser’s capabilities.
The object tag in theory is a good idea, but has a
slightly twisted history. It originated as the ActiveX
equivalent of applet (with codebase
and classid attributes), and was later extended to
take on the duties of img, applet,
embed, and iframe. This has left it
with more than one way to indicate which plug-in is used to
display its content. Generally the plug-in should be implied by
the media-type of the embedded resource (indicated with the
data attribute):
<object data="frog.swf" width="400" height="300"
type="application/x-shockwave-flash"
>
...
</object>
The browser is then responsible for locating a plug-in that
handles this format.
When the object tag was first introduced, it used
attributes classid and codebase to
identify the plug-in explicitly:
<object classid="clsid:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
codebase="http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
width="400" height="300" ...
>
<param name="movie" value="frog.swf" />
...
</object>
The problem here is that it is tying you to a particular implementation of Flash, the one for Microsoft Windows (ActiveX). Browsers that do not have support for ActiveX controls cannot use this, so cannot display the content.
If I were king of HTML for a day I would deprecate
these funky parameters; they should not be needed. (The Flash
Satay article (on A List Apart) describes this as working in
Gecko browsers and almost working in Microsoft Internet
Explorer.) I would consider deprecating the type
parameter as well; it causes confusion by giving authors the
illusion of control when in fact the media-type reported by the
server takes precedence.
The object tag has another complication: it might
or might not be interactive. HTML has a mechanism for making
simple images (like GIFs and PNGs) clickable: client-side
image-maps. These do not work with, say, applets, because the
applet plug-in is responsible for handling mouse events, so the
HTML processor never gets a chance to pass them on to the image
map. Presumably the handlers for these images’
media-types will need a special interface that allows them to
access client-side image-map data.
But alas! it will be a while before we can use
object elements everywhere, because Safari
1.0’s support is broken.
The irony is that Safari handles embed really
well—they display just like images included with
embed, which is just as it should be (some other
browsers get all weird and lay out pages with images handled by
plug-ins differently from those handled internally). If only
object elements did not cause it to crash.
You cannot upgrade Safari for free; versions 1.1 and 1.2 only work with Mac OS X 10.3, leaving older Macs running 10.2 stranded with Safari version 1.0. The rule of thumb seems to be that we stop worrying about support on a given web browser version after it has been abandoned for five years; Safari was released in 2003, so its bugginess has to be taken into account until 2008. Pity.
