[whatwg] WhatWG and <embed>

[Shadow2531]

On 9/1/06, Christian Biesinger <cbiesinger at web.de> wrote:
> Shadow2531 wrote:
> > 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. )
>
> Personally I don't mind the <object><embed></object> way really :)

:) Yeh, it's not THAT bad.

> > <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.
>
> I'd rather see IE work without specifying classid, then this would work
> without any new attributes...

Oh, same here.

> > 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.)
>
> I would like the spec to say that, indeed. (A while ago I asked a few
> questions about how <object> should behave on this list, btw).
> > 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.
>
> Ew...

As in "No way!" or 'Ew' as in "I hate that IE does that!" or other?

> > 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 )
>
> Why is that OK? Which browser does that? And why not specify that either
> way must be done, instead of allowing both?

It's O.K., if it makes the plugin work, which is what matters. If the
plugin doesn't know what 'data' is, you map it to something else like
'src'. If the plugin doesn't know what 'codebase' is, you map it to
something else like 'baseurl' in the case of WMP.

An example that Firefox and Opera both do:
<https://bugs.helixcommunity.org/show_bug.cgi?id=4766>

I'd like the spec to describe exactly how browsers should do stuff like that.

As for the priority deal. Here's an example:

<object codebase="http://somesite.com/dir/">
    <param name="baseurl" "http://someothersite.com/">
</object>

If the browser must map codebase to baseurl for a certain plugin like
WMP to work with the object element, if both are specified, does the
codebase still map to baseurl or can the browser give the actual
baseurl priority and not map. It could be done a few different ways.
All I'm saying is I'd like it spelled out so everyone can stick to it.

Another example WMP example:

<param name="autostart" value="false">

does nothing for the WMP netscape 6.4 plugin that Opera and Firefox
(normally) use.

Instead of 'false', it has to be '0'.

Should browser's be allowed to map false|true to 0|1 on a
plugin-by-plugin basis in this case to make things work?

I know it's MS's fault for this or Real's fault in the other case, and
there are markup ways around it, but I'm saying that browsers have to
do all kinds of things to make plugins work, because most plugins
suck.

The thing is, if all browsers are not working around the problems is
some common way, it doesn't help. If half are using duct tape and half
are using elmer's glue, we're still stuck with cross-browser
incompatibility.

Maybe this stuff is beyond the spec, but I bring it up for everyone to decide.

> Presumably it's the plugin itself that handles those attribute mappings.

Sometimes we know better than the plugins.

There's just too much undefined behavior when it comes to
object/embed. Let's add some detail. :)

-- 
burnout426