Re: <object> element

Joe D Williams wrote:
> classid started out in IE and became useful to me when different X3D 
> players adopted their individual classid values. But classid was limited 
> to IE and would never work in other html browsers and often (more like 
> everytime, with aggression) broke any object element that included a 
> classid. I always wondered why clasid didn't work everywhere.

Precisely because it works as you want.  IE uses ActiveX plug-ins.  The 
classids you specify refer to those particular plug-ins.  Other UAs use 
NPAPI plug-ins, which you're explicitly saying you don't want when you 
use the ActiveX classid values (anything starting with "clsid:" and 
followed by a UUID).

Note that non-IE browsers do support some values of classid (e.g. 
"java:something" values).

> Anyway, for this to work meaningfully then processes the plugin uses to 
> register classid must be as open and easy and predictable as when 
> registering MIME type and file extension handling.

Yes, indeed, but it's not.  And worse yet, since classid as currently 
defined means a particular implementation you'd need different classids 
for, say, Flash on Mac and Flash on Windows (esp. since they they do in 
fact differ in behavior).  At which point your site above would suddenly 
break for all Mac users unless you were much more careful than the 
typical web developer.

The edge case of selecting a particular plug-in if the user has several 
different ones that all handle the same type _and_ is not capable of 
picking one himself _and_ the web developer knows what the user has 
installed _and_ the web developer is capable of making that choice well 
doesn't seem to be worth the many ways the feature can be accidentally 
misused without realizing it.  For example, any use of an <object> with 
classid without a fallback that renders purely based on MIME type would 
be such a misuse...

-Boris

Received on Monday, 1 June 2009 17:15:26 UTC