Re: [whatwg] <video> element feedback

On 3/29/07, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Mar 29, 2007, at 08:04, Boris Zbarsky wrote:
>
> > Laurens Holst wrote:
> >> So, what do you think would be needed to fix this situation.
> >
> > In my dream world, IE would support dispatch by MIME type and
> > authors who don't care about targeting a specific plug-in binary
> > could just stop using the classid mess.
>
> I've asked about this before but I still don't understand it: Why
> doesn't Gecko completely ignore the classid? (IIRC, Opera on Mac and
> Mac IE 5 ignore the classid and dispatch on MIME.)

Here's just one  example of what Boris is referring to with different
implementations.

<object classid="clsid:6BF52A52-394A-11D3-B153-00C04F79FAA6"
type="application/x-mplayer2" data="file.wmv">
    <param name="URL" value="file.wmv">
    <param name="AutoStart" value="false">
    <param name="Volume" value="50%">
</object>

That classid invokes the Windows Media 7+ ActiveX control.  If FF
ignores the classid and uses type and data, FF will be using the
Netscape WMP 6.4 plug-in.

For the 6.4 plugin (which is older than dirt, but all there is
netscape-wise because MS has abandoned it (and even broken
compatibility with it in WMP11)), boolean values coming from params
have to be 1 or 0. True or false are not understood. In this case, the
video would still autostart.  Also for the 6.4 plug-in, volume is
different. It doesn't want a percentage, it wants -10000 to 0
(logarithmic scale).  The 6.4 plugin also doesn't understand URL, it
wants a filename param. There are also other params that only exist in
one of the implementations.

Now, for that to work, FF would have to convert false to 0 before
passing to the 6.4 plugin. It would have to convert 50% to ~ -612
before passing to the plug-in. It would have to convert URL to a
filename param before passing to the plugin.

Since the plugin doesn't understand a data param, FF already has to
map data to filename, so, in this case, that part at least is not a
problem, but the rest of the compatibilities still are.

Also, the codebase attribute in this case (if it was present) would
have to be checked by FF first to make sure it wasn't a path to a .cab
file (for IE) before it was used to resolve a path for file.wmv.

Further, FF would have to do all these type of things on a per-plugin
basis for every plug-in where the ActiveX version exposed a different
api compared to the netscape version.

Even more, the JS methods exposed on the object between the 2 APIs are
very different.

However, if the wmp classid of
"clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" was used, that would
invoke the WMP 6.4 ActiveX control where the author would be using
6.4-compatible params where param converting would not be needed. So,
there's have to be a condition where converting would not happen.

So, it's possible for FF to ignore classid and have things work fine,
but I assume there'd be a lot of bloat going on behind the seen to
make sure that it happens correctly.

If other browsers ignore classid and things work out, there's most
likely a bunch of converting going on to make it work, but it will
still probably break in advanced situations.

Now, if you want nested objects, IE7 will handle that. If you're
worried about IE6, we can use downlevel-hidden IE conditional comments
for that.

-- 
burnout426

Received on Thursday, 29 March 2007 22:43:55 UTC