Re: <object> element

Joe D Williams wrote:
>> For example, any use of an <object> with classid without a fallback 
>> that renders purely based on MIME type would be such a misuse..
> 
> OK, we won't do that.

Web pages already do it, I should note.

> Since I saw classid in the plugin instantiation steps and since I 
> thought I saw some W3C browsers had stopped failing on it, I was hoping 
> this had progressed to a generalized feature not limited to ActiveX in 
> IE.

Safari has a short list of ActiveX classids that it internally maps to 
particular MIME types.  It then dispatches on MIME type.  This might be 
what you saw.

> I was thinking of classid as a generalized registration 
> alongside MIME and file extension lists. But who would maintain 
> registration process and classid uniqueness?

Right now, for clsid:* IDs, no one.  But those use long enough strings, 
generated via a process that makes collisions highly unlikely, so that 
non-uniqueness is not an issue in practice.

Heck, you could use the SHA-512 signature of the plug-in binary as the 
classid if you wanted, if you just need to guarantee uniqueness.

> The classid attribute is always optional (and should be read-only?). For 
> general purpose, unless targeting specific features of a particular 
> player for that MIME, I would never need to use it

You have a lot more clue than most people writing web pages, sounds 
like.  ;)

> I guess would be completely up to the plugin maker to decide how to 
> register the plugin and includei a classid. 

Right.

> Maybe the plugin maker would think it best to define a different classid when the 'same' 
> application plays the same mime on different platforms, I would probably 
> say to use the same classid if it was the 'same' application feature set 
> just packaged for a different platform.

It almost never is; you end up with platform-specific bugs...

> I'm not sure the browser user gets to choose from multiple plugins that 
> play the same MIME now.

That's a bug (at least from my point of view as a Gecko developer, I 
consider it a Gecko bug).  We do plan to fix it, last I checked.

> I think multiple W3C browsers are looking more 
> consistent; I think the last MIME handler installed/registered should 
> get used.

Note that users can disable or enable plug-ins on the fly already in 
some browsers, so it's not order of installation that ends up mattering 
here.  In general, how a browser decides which of multiple plug-ins that 
can all handle a type is used is up to the browser.

It'd be really nice if plug-in registration registered q values in 
addition to types, but that's not a web-facing issue, of course...

-Boris

Received on Monday, 1 June 2009 22:40:53 UTC