[whatwg] <object> element feedback

Thanks.

On 5/6/08, Ian Hickson <ian at hixie.ch> wrote:
>  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.

As for the other issue, there are some type attribute values that are special.

<object type="application/x-mplayer2" data="file.gif(sent as
image/gif)"></object>

That really means to load the gif file in the plugin and not with the
browser's native gif handler. But, according to the spec, FF3 and
Opera, you have to send file.gif as application/x-mplayer2 to
accomplish that. FF2 behaves as expected.

This is really a data attribute issue though. To workaround it, you
can get rid of the data attribute and load it this way:

<object type="application/x-mplayer2">
    <param name="filename" value="file.gif(sent as image/gif)">
</object>

So, in short, when you're dealing with plugins, to get the expected
behavior, you often have to avoid the data attribute and use the
plugin's param that it uses for loading resources instead.

>  > 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
>  > attributes?
>
>  It appears it should fail. Do browsers do otherwise?

Opera currently doesn't let classid get in the way. It will ignore it
and still use the object. Other browsers don't agree though.

One problem with Opera supporting this is that the object might have a
codebase attribute on it that points to a cab file for IE, which can
mess up the path resolving of the data attribute. Since other browsers
fall back when there's a classid, they usually don't get this problem.

>  > How should data uris be handled?
>  Isn't this up to the plugin API?

It's currently up to the plugin api and the particular plugin. I just
think more plugins should support data URIs though and maybe there'd
be a way for browsers to fill that gap.

>  > 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?

Ideally, codebase should be a base href for the data attribute, but
only be allowed when used with handlers that *properly* support the
data attribute for loading the resource. Of course, you can't really
validate that.

>  > 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.

O.K.

>  > 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.

O.K.

>  > 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.

O.K.

>  > 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.

O.K.

>  > ( 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.)
>
>  Really?

I'll explain.

Consider this:

<object type="application/x-vlc-plugin">
    <param name="mrl" value="file.ogg">
</object>

The videolan plugin doesn't request file.ogg from the browser. It
downloads it itself. If you specify a data attribute, the browser will
just download the file in the data attribute and the plugin will
ignore it.

With the following, if a browser maps data to mrl for the videolan
plugin (because authors expect data="" to work for everything), the
file will get downloaded twice.

<object type="application/x-vlc-plugin" data="file.ogg"></object>

So, in this case, when mapping data > mrl, the browser shouldn't fetch
the resource in the data attribute. But, browsers always fetch the
resource in the data attribute.

The Windows media plugin does stuff like that too where it insists on
downloading the file itself.

I guess there's nothing the spec can do about this though and this is
just another situation where data="" needs to be avoided.

>  > 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.

Yes, ignore this.

>  > 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.

Ignore this also.

>  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
>  out.

O.K.

>  On Sat, 7 Apr 2007, Michael A. Puls II wrote:
>  >
>  > Currently, the only way to embed an applet that's allowed by the spec
>  > is:
>  >
>  > <object type="application/x-java-applet">
>  >    <param name="code" value="MyJavaClass">
>  > <object>
>  >
>  > (That works fine for Opera and FF at least.)
>
>  Indeed.

Yeh, it's just another case where you can't use data="".

>  > 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.

Thanks.

>  > 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.

That's good enough for me.

>  > 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.
>
>  o_O
>
>  I'd rather just not support it and make it non-conforming... Do any
>  browsers actually support case 1?

Opera and Firefox support #1 and it works really well (for native
handlers at least) if you use it properly.

>  > 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
>  > exception.)
>  >
>  > With all the different OBJECT situations for Java, APPLET will be a huge
>  > relief.
>
>  How about just not supporting Java?

That'd be easier.

>  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
>  > though.)
>
>  It's not clear to me how this is supposed to work. Does the NPAPI define a
>  way to submit form data?

As Vlad said, HTML4 says objects can be submitted via forms. This
happens when the object has a name and the object loads a plugin that
exposes a value getter.

This doesn't work completely across browsers, but it's essential for
the xstandard plugin.

>  > > 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.

Not sure about making it valid or not, but for the handling section,
something like the following (but maybe more specific) would probably
do.

If the classid attribute is present, then the codebase attribute
behavior is defined by the classid handler.

If classid is not present and data is present, it specifies a base
href for the data attribute.

-- 
Michael

Received on Tuesday, 6 May 2008 04:38:34 UTC