[whatwg] <object> element feedback
ian at hixie.ch
Mon May 5 23:08:15 PDT 2008
On Sat, 7 May 2005, Christian Biesinger wrote:
> OK, another <object> fallback question: Consider an object that has no
> attributes that would allow selecting a plugin/content handler. For
> simplicity, consider an object without any attributes, say:
> What should be displayed? Should the user agent just fall back to the
> contents of the object? (Presumably "empty string" as fallback content
> does not affect the answer to this question either :-) )
The spec now defines this.
On Wed, 25 Jan 2006, Hallvord Reiar Michaelsen Steen wrote:
> On encountering an OBJECT, the UA must check type and/or classid.
> If the type attribute identifies a file type the UA handles
> internally, check if the OBJECT has a data attribute. Render contents
> of this attribute if found, proceed to fallback contents if not.
> If type/classid identifies a known plugin, the UA must initialise the
> plugin passing on information about the attributes and the name/value
> pairs of any PARAM descendants that are not children of nested OBJECT
> If type/classid does not identify a known plugin, and there is a data
> attribute, do a HEAD request on the resource identified by the data
> attribute. If the server sends a content-type that identifies a known
> plugin, initialise plugin.
> If there is no data attribute, the resource can not load or the
> content-type of the resource is unknown, proceed to render fallback
The above is somewhat what the spec says, though it is more closely
aligned with what browsers (Mozilla in particular in this case) seem to
> Issues: if there is a known content-type and a data: attribute,
> should the UA check if the content-type sent from server also
> identifies the plugin? In other words, do we want to say that the
> type attribute on the OBJECT tag is only a hint and that the actual
> HTTP content-type header is the one that counts?
Right now the spec uses the Content-Type header if it is present.
> I'm not sure if "only a hint" should be speced. It sounds quite risky to
> meddle with the logic for embedding contents - could break many sites,
> particularly if we are supposed to start relying on the famously
> malconfigured HTTP content-type responses.
What should it be instead?
> Since there are use cases for plugins that do not load data at all, the
> UA should initialise the plugin even without data attribute if the type
> is known. That sort of negates the point about type being a hint because
> we can't initialise one plugin, look at the content-type of files that
> plugin decides to request and say "whops, we started the wrong plugin,
> let's do this again". If the spec goes the "hint" route, it really needs
> to make that apply only to OBJECTs with a data attribute, and to
> minimise problems with malconfigured servers it should only take place
> if the UA doesn't know the specified type attribute IMO.
Right now if type="" is present but data="" isn't then the respective
plugin is fired, otherwise the plugin to fire is taken from the
> Another issue is of course if and how one should map classid to plugins.
Indeed. I don't know how to do that. I suppose it is UA-specific.
On Tue, 31 Jan 2006, Shadow2531 wrote:
> The current methods of "The server Content-Type rules all" and "If
> there's no data attribute, then fail" are not working out. There are
> cases where a data attribute is not needed and there are cases where a
> type attribute should be the priority. The type attribute is really used
> as "Here's what plug-in/handler I want to use".
For the no-data="" case, the spec now handles it.
> There also needs to be some specifics for the classid attribute. If the
> classid contains an unsupported naming scheme, should the UA really have
> to just fail or should it go on and try to use the type and data
It appears it should fail. Do browsers do otherwise?
> How should data uris be handled? Is it just up to the plug-in to handle
> the passed data uri or is the UA allowed to create a file from the data
> URI and pass the file path to the plug-in/hander (if it can do it
Isn't this up to the plugin API?
> What should happen when a UA encounters a codebase attribute that has a
> path to a cab file instead of a base URI? Should the UA always use the
> codebase to resolve URIs even if it has junk in it?
Right now codebase="" is just ignored by the spec. What should it do?
> First, the UA should check for a classid attribute.
> If present and the the UA has a handler associated with the specified
> naming scheme, then the UA should pass all arguments to the handler in a
> manner that is specific to the handler.
That's what the spec says, indeed.
> If the classid attribute is not present or the naming scheme is not
> supported or the handler returns an error code, then the UA must check
> for the presence of a type attribute.
If classid="" isn't supported, it just shows fallback.
> If it exists, the UA must check to see if it has a handler associated
> with the Content-Type specified in the type attribute.
> If the Content-Type is associated with a handler, the UA must pass all
> arguments to the handler.
The resource is actually downloaded by the UA in this case, as far as I
can tell. Is that wrong?
> If that fails and there is a data attribute, check the Content-Type
> sent by the server for the file and determine if there's a handler
> associated with the type.
The spec honours the Content-Type header over all else if it is present
and classid="" isn't.
> If there is a handler associated with the type, pass all arguments to
> the handler.
> If there is not, the UA *should* compare the file extension to a list
> of known Content-Types associated with that extension.
> If a handler is found, pass all arguments to the handler.
I do not want to add any extension-sniffing to the spec, it is too
dangerous, highly unreliable, and as far as I can tell isn't necessary.
> ( URIs to files should be passed to the handler and the handler should
> download the files as necessary. The Ua should not download the file on
> its own. Only the handler should make that request to the UA.)
> Once the handler gets the arguments, it *must* detmermine whether it has
> the necessary and valid arguments to initialize. If it does not, it
> should return a failure code. If it does, it should try to initialize
> and if successful, return a success code; otherwise, return a failure
> code. The handler should return a failure code in every situation where
> there's no need to initialize in the first place.
This is out of our scope.
> The UA must check for this return code to determine whether to display
> fallback content.
It's not clear to me how to tell if a plugin failed.
On Wed, 1 Nov 2006, Christoph Päper wrote:
> I think it would be helpful to /explicitly/ allow content types (alias
> media types) in |type| of |object| to omit the subtype, e.g.:
> <object type="video" data="foo.mpv"/>
> <object type="audio" data="foo.mpa"/>
> <object type="image" data="foo.png"/> ~= <img src="foo.png">
> <object type="application" data="foo.swf"/> ~= <embed src="foo.swf"/>
> <object type="text" data="foo.txt"/> ~= <iframe src="foo.txt"/>
> Maybe this is all the support for this element type that should be
> required from conforming implementations. Furthermore |width| and
> |height| should be required for freely scalable formats, but OTOH not
> apply to 'audio' types (i.e. always equal zero), and exclude the space
> required for an optional inline GUI.
> I never understood, by the way, why videos and Flash-like content
> shouldn't work within |img|. (Parameters can be specified in URIs.)
> I could also envision an HTML5 where |alt| was optional for (or even
> removed from) |img|, which in return was only allowed to be used for
> optional, decorative images (and perhaps likewise |embed|). Every
> illustration conveying meaning was then to be embedded using |object|
> (including descriptive content, but nesting |object|s would be
> discouraged, although allowed) or more sophisticated methods. This
> wouldn't keep many correctly authored existing pages conformant, though.
I don't really see how to handle this feedback. We can't really make the
changes that would change how <object> works today.
On Tue, 7 Nov 2006, Lachlan Hunt wrote:
> Should the data attribute be required for <object>? There is at least
> one plugin that doesn't need it. XStandard embeds itself without using
> it, like this:
> <object type="application/x-xstandard" id="editor1" width="100%" height="400">
> <param name="Value" value="Hello World!" />
> I'm not sure whether that's a correct use of the object element or not,
> and I do think it would make more sense for XStandard to replace a
> textarea, but there must be implementation issues with that or
On Tue, 7 Nov 2006, Shadow2531 wrote:
> Reason 1:
> <object classid="java:MyJavaClass"></object> is used for Java. (
> Although I'd love to have <object type="application/java"
> data="file.class"></object> work, but ...)
This is not allowed. Java should use the standard mechanism, as you point
> Reason 2:
> You might want to load a plugin like this: <object
> type="application/x-mplayer2"></object> and later use scripting to
> tell the plugin to get the resource. If the data attribute is
> required, you'd be forced to load a resource that you didn't want to.
> Reason 3:
> The tcl plugin <http://www.tcl.tk/software/plugin/> suports inline
> scripts via a script param and things like the following need to work
> without the data attribute.
> <object type="application/x-tcl">
> <param name="script" value="script content">
On Sat, 23 Dec 2006, Rohan Prabhu wrote:
> I've been writing a spec called 'XObject' for the past week.. and i'm
> going on a 2-day vacation from tomorrow.. just got the idea of sharing
> this with you. I wrapped it up in a small site-like thingy in the short
> time i had.. so the site is not really good... but the content is there
> as much as i have worked on. It is still a work in progress. Do read the
> foreword there, I've already warned about some factual inaccuracies...
> Here is the link to it: http://xobject.tritiumx.com
It's not clear to me what this spec (which btw is now no longer available)
was supposed to address.
On Sat, 7 Apr 2007, Henri Sivonen wrote:
> HTML5 should probably make the Java applet embedding patterns documented by
> Sun conforming or at least make the <applet> case conforming as it is the
> cross-browser syntax:
Java needs to get over itself and stop being such a drama queen and just
use the standard embedding methods that everyone else uses.
On Sat, 7 Apr 2007, Michael A. Puls II wrote:
> Currently, the only way to embed an applet that's allowed by the spec
> <object type="application/x-java-applet">
> <param name="code" value="MyJavaClass">
> (That works fine for Opera and FF at least.)
> There's also <embed type="application/x-java-applet"
> code="MyJavaClass">, which is currently not allowed because src is
> There's also <object classid="java:MyJavaClass> (which is used as a
> non-deprecated example at
> <http://www.w3.org/TR/html4/struct/objects.html#h-13.4>). This is
> currently not allowed because there's no classid allowed, which has to
> be present to be compatible with IE.
> And, then, there's of course APPLET, which needs to be defined (no
> rush), including how fallback content works when java support isn't
> present and the alt attribute is present. (As in, does alt get used over
> fallback content or the other way around or somewhere in between.)
There's a note in the spec about this.
> I also think it might be necessary to clarify (or at least hint to)
> what mime type should trigger java. application/x-java-vm and
> application/x-java-applet etc. are provided by the Sun Java plug-ins,
> but not all browsers use those plug-ins. (application/java is used in
> W3C examples.)
The spec has an example with x-java-applet now.
> On a side, if codebase is allowed on the object element, it will have 3
> different uses.
> 1. base URI for resolving (kind of like <base href="">)
> 2. URI to a .cab file (for activeX stuff)
> 3. For java, it's specifically a URI to the directory the .class file
> is in unless you're using current IE in which case, it's #2 and a
> codebase param is used instead.
I'd rather just not support it and make it non-conforming... Do any
browsers actually support case 1? Case 2 seems incompatible with case 1.
> In the case of #3 (for browsers besides current IE), where both a
> codebase attribute and a codebase param are present, one of them would
> have to override the other. It might be necessary to define which one
> and how etc. (Going to something specific like this might be out of
> scope for plug-ins etc. in general, but Java handling might be an
> With all the different OBJECT situations for Java, APPLET will be a huge
How about just not supporting Java?
On Mon, 22 Oct 2007, Vlad Alexander (xhtml.com) wrote:
> I noticed that the latest HTML 5 draft states that the "name" and
> "codebase" attributes are not allowed on the "object" element.
> 1. Plug-ins, such as XStandard, use the "name" attribute for submitting
> accessible solution. XStandard has been doing this for 4 years in some
> browsers. IE, Firefox and Opera support this feature. This attribute
> serves a vital role for plug-ins.
name="" is now supported, though not for this purpose.
> 2. The "codebase" attribute is the only way to auto-install or update
> plug-ins in IE. This is an important feature that should not be removed
> without providing an alternative solution.
I take it you don't like the idea of HTML+JS being the alternative
Auto-installing unprotected binary code on an enduser machine seems
> 3. The HTML 5 draft states that the "embed" element is used for plug-in
> content. The "object" element is a better mechanism for loading plug-ins
> and is supported by all browsers. The HTML 5 spec should state the
> "embed" or "object" elements can be used for loading plug-ins.
I'm not sure which bit you're referring to here.
On Thu, 25 Oct 2007, Michael A. Puls II wrote:
> Yes, I agree. The name attribute has to be supported (at least when the
> object is inside <form>. (All the form stuff hasn't been dealt with yet
It's not clear to me how this is supposed to work. Does the NPAPI define a
way to submit form data?
> > 2. The "codebase" attribute is the only way to auto-install or update
> > plug-ins in IE. This is an important feature that should not be
> > removed without providing an alternative solution.
> If we do define it, it's going to be fun because what it's for depends
> on how it's used.
> It can be a URI to fetch a new version (for IE).
> It could be the directory that java class files are in (in browsers
> besides IE when using the Sun java plugin).
> It could be a base URI used for resolving relative URIs (in browsers
> besides IE for possibly native stuff and some plugins).
> For the last 2, there would need to be rules to follow to determine
> whether it's an IE upgrade URI or a base URI so browsers besides IE
> don't use it as a base path if it's not really a base path. But,
> there's not much need to use a codebase attribute in FF, Opera and
> Safari (not even for java).
I have no idea what to do here.
On Tue, 1 Jan 2008, Jeff Walden wrote:
> Firefox 2 shows FAIL.
> Firefox 3 currently shows PASS.
> WebKit nightly shows a broken image icon.
> Opera 9.25 shows PASS.
WebKit now shows PASS, so this seems like a non-issue. (Spec agrees.)
> For the moment ignoring that WebKit's using @type instead of the
> server-sent type of the <object> producing the PASS/FAIL/icon (contrary
> to current HTML5 and HTTP RFC 2616), it seems that WebKit isn't
> displaying fallback content when the primary content contains "errors"
> -- malformed images, in this case -- where recent Firefox and Opera are.
> The spec doesn't currently address falling back for malformed content,
> i.e. malformed images, invalid XML (maybe?), content a plugin handler
> declines to handle (?, dunno whether this is expressible in NPAPI or
> ActiveX or whether that question's too implementation-dependent), etc.
> I tend to think it should since a broken-image icon's not particularly
> useful, but I don't care strongly one way or the other.
Fixed for everything but XML.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg