[whatwg] WhatWG and <embed>

On 8/21/06, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Shadow2531 wrote:
> > If classid and data are both present, Firefox ignores the data and
> > gives the classid a shot. If there's no activex plug-in installed that
> > handles the clsid, Firefox fails and goes to alternate content.
>
> You mean "type", not "data", right?  And actually, all non-java classids just
> make Firefox show the alternate content, unless you have the optional ActiveX
> stuff installed.

Type may be required to trigger that behavior, but yes we're talking
about the same thing.

> > It looks like you're saying that people that target the activeX method
> > don't want to fall back on the NPAPI method.  But, what if an author
> > wants to?  You'd probably say to use alternate content and another
> > object tag or embed tag.
>
> Yep. That's the whole point of <object> having alternate content.
>
> > However, I think it'd be neat to fall back (or give the option through
> > an attribute or something to fall back ) on the data off the current
> > object element.
>
> Why reinvent the wheel?  There is already a way of doing fallback with <object>.
> > Opera doesn't do classid stuff (except for java) so it can ignore the
> > classid and use data.
>
> In my opinion, this is a bug in Opera; one they introduced to be more compatible
> with IE in many cases (and that breaks other cases, sometimes badly).

Yes, it's arguably a bug, but I do like this bug because I can use
only one object element to do IE's classid way and the normal way.
It's a compatibility feature imo.  However, I can't use it in
production without breaking FF or adding alternate content or doing IE
conditional comments or other ways.   ( IE doesn't like nested objects
very well without some css hacks. )

For example:
<object codetype="type"  classid="clsid:123456" type="type" data="file.ext">
<param name="src" value="file.ext">
</object>

Something like that would work fine in both IE and Opera. In Firefox
that would break if there wasn't an activeX plug-in installed to
handle that particular clsid.

Now:
<object fallondata="true" codetype="type"  classid="clsid:123456"
type="type" data="file.ext">
<param name="src" value="file.ext">
</object>

could be an answer to this.

fallondata would allow the author to choose the compatible way like
Opera does, but not using fallondata would allow the author to do
things the normal why like FF.

Compatibility and control are the use-cases for fallondata. I wouldn't
consider it reinventing.

Maybe Mozilla can compromise for IE-compatiblity. If not, we need the
spec to say specifically that classid must be tried first and using
the data attribute after that must not happen.  ( It's seems there are
interpretation differences with the current spec and I'd like there to
be no doubt what should happen.  Then, we can fix bugs.)

Also, IE's current use of  the codebase attribute is of course wrong
according to HTML 4.01.  I'd like to see something in the spec like
"The UA may ignore the codebase if it is determined that it does not
contain a base IRI".  Basically, ignore codebase if it has known URIs
to cab files etc. in it.

Also, I'd like to see mention in the spec that it is O.K. to map
object element attributes to other params for plug-ins that don't
conform to object element handling. For example, mapping codebase ->
baseurl and data -> filename for WMP. I'd also like to have it spelled
out what happens with mapping if both codebase and baseurl are
present.  (Like which one gets priority )

On a side note, what do you think about mayscript for the object element?

Currently, for applet -> js communication, this is how I need to do it in Opera:
<object classid="java:MyJavaClass" codetype="application/java">
<param name="mayscript" value="true">
</object>

Does FF need that or does the java plugin automatically allow applet
-> js communication.

Mayscript is something we might need to define.

Thanks

@Christian
Sorry to mix in some object element stuff into your embed discussion,
but object kind of gets implied when you mention embed.
-- 
burnout426

Received on Monday, 21 August 2006 15:48:46 UTC