Re: <object> element

Hi Boris,

> 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.
To construct an object element without using progressive fallback to 
most accessible native media is a degree of misuse. Fortunately you 
get to select MIME type for each level of fallback so there should not 
be any surprizes. The steps for getting the plugin running should 
handle the case when host can't find a requested classid.

>  IE uses ActiveX plug-ins.

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. I actually haven't looked at the detail of whether or 
not any other than IE are actually honoring or at least ignoring 
classid at this time. A big part of improvement in object element 
performance in the latest browsers is better recognition of the 
registered MIME to pick the plugin. I was thinking of classid as a 
generalized registration alongside MIME and file extension lists. But 
who would maintain registration process and classid uniqueness? 
Without classid the last application that registers the MIME gets to 
play.

> a particular implementation you'd need different classids for, say, 
> Flash on Mac and Flash on Windows  ... 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 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 and the 
last plugin the user installed for that MIME would get the job. In the 
current steps, classid is above MIME selection if the author includes 
a classid. I guess would be completely up to the plugin maker to 
decide how to register the plugin and includei a classid.  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.

> 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

I'm not sure the browser user gets to choose from multiple plugins 
that play the same MIME now. I think multiple W3C browsers are looking 
more consistent; I think the last MIME handler installed/registered 
should get used.
True, the developer has got to know all that stuff you mentioned to 
use classid.

> you'd need different classids for, say, Flash on Mac and Flash on 
> Windows (esp. since they they do in fact differ in behavior).

That is too bad, that they are not the same but different.
If I was depending upon a certain feature set, I would like to know 
about that and maybe deal with it as early as possible.

> doesn't seem to be worth the many ways the feature can be 
> accidentally misused without realizing it.

In my little toolbox this just gets used when, at some level of object 
fallback, there are are multiple registered players for the MIME and I 
want to try to pick one. Perhaps for some specific (workintg) feature, 
or even some loyalty, or some other author-defined purpose. In a sense 
the classid doesn't have much to do with the user - more like info 
shared between the plugin maker and the web developer, along with 
cooperation of the W3C browser. Including classid does not imply any 
different user interaction than if classid is not included. The user 
may get involved if permissions are needed to progress and most all 
browsers are working better there also,

Thanks and Best Regards,
Joe

Received on Monday, 1 June 2009 19:37:37 UTC