[whatwg] WhatWG and <embed>

[Shadow2531]

On 9/4/06, Christian Biesinger <cbiesinger at web.de> wrote:
> Shadow2531 wrote:
> >> > "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?
>
> "Ew" as in "I wouldn't want to see that text in any spec".

O.K. Thanks

> > 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.
>
> Gecko maps data to src (in case of <object>), but that's all. It
> certainly doesn't map codebase to anything else.
> > As for the priority deal. Here's an example:
> >
> > <object codebase="http://somesite.com/dir/">
> >    <param name="baseurl" "http://someothersite.com/">
> > </object>
>
> See above re codebase. (Although, note that Gecko uses codebase as the
> base URI for resolving the data attribute, and it passes the data it
> receives from the resulting URI to the plugin).

Yes, codebase + data -> src is great and universal.

However, see <http://shadow2531.com/opera/testcases/plugins/wmp/004.html>

That works in Opera, but doesn't in Firefox. It seems that Firefox  is
not using the codebase to resolve the data attribute before mapping it
to src.

Opera either does codebase + data -> src , or it does codebase ->
baseurl (for wmp only) and data -> src and lets the wmp plugin do the
resolving.

Either way, it works in Opera, but the difference is that with the
latter, the plugin itself does the resolving.  If you actually want
the plugin itself to do the resolving, and the plugin doesn't know
codebase, I think you should be allowed to make things work.

Now as for the priority question, I just answered my own question.  If
doing codebase + data -> src  ( like Firefox does or is supposed to do
) for WMP, the baseurl param wouldn't matter. That would mean in the
situation of codebase -> baseurl and data -> src, if baseurl is
present it would not matter and codebase gets priority.

With said, there could be something in the spec about that, but I
believe it's implied now by codebase + data rules, so I drop the
suggestion.

> > 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?
>
> On a plugin-by-plugin basis? That would be insane, IMO. Why make
> browsers do this? Only the plugin itself knows how to interpret a
> certain parameter value. The browser doesn't even know the data type.
>
> >> Presumably it's the plugin itself that handles those attribute mappings.
> >
> > Sometimes we know better than the plugins.

Yes, the WMP plugin handles the params itself, but only with activex
does it accept true/false. With the netscape version, it's 1/0. Now
that's not a big deal if you use totally separate params for each
version, but if you want to use the same params for both, it's a
problem if the activeX plugin interface doesn't map 1|0 to true|false.
 Besides, Microsoft's documentation says it should be true/false.

It's the wmp netscape plugin and MS's documentation that's the
problem, but they're never going to fix it, which is why I think it
should be allowed to make things work even if it is the plug-ins
fault.

In other words, <param name="autostart" value="false" doesn't work for
WMP unless you're using activex. It has to be value="0" for it to work
for the netscape version.

I'd love to see it work with 'true", but ....

I think Gecko did map true -> 1 and false -> 0 before passing to wmp
at one time, but that has changed. If I can find a bug report on that,
I'll certainly show you, but it's not important as Firefox doesn't do
that anymore.

To sum things up, there needs to be a set or common way of making
pain-in-the-butt plugins work, but again, I guess this is beyond the
spec.

> OK, can you point me to the code in Gecko that does the mappings you
> mentioned? (except the data/src one, which is at
> http://lxr.mozilla.org/seamonkey/source/layout/generic/nsObjectFrame.cpp#2477)
>
> > There's just too much undefined behavior when it comes to
> > object/embed. Let's add some detail. :)
>
> Seeing as I don't think current browsers do most of those mappings, I
> don't quite see the point of specifying them...

Yeh, see above.  Thanks

-- 
burnout426