Re: <object> element

> 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.

Yes, I think maybe that is when Safari started working for me. Thank 
You all very much..

>> 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.  ;)

Thank You, If it is reasonable and reliable then I can mostly probably 
get some clueness. I think plugin features to extend html are 
necessary and the <object> element gives us some leverage into that 
space. Lots of examples can show that plugins can work with the DOM 
and other host services. All of the W3C browsers are making it easier 
to find, install, then run simple and complex plugins so that is 
great.

>> 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...

Sorry, that is not acceptable.  Maybe HTML5 and plugin innovations 
will help to reduce that. For <audio> and <video> it looks like 
convergence to a feature set that should help html a lot. Does this 
potential of having several registered plugins and the possible need 
for operator intervention happen there? I will look. Hmm, type for 
MIME shows up in <source>. Quite a bit of fine develoment going on 
there.

>> 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.

Well, I mean if I give a registered type in the <object> code, then it 
should pick the current default user pref and just run it. Some user 
prefs may ask if the user wants to run the current default plugin, but 
that is not the place to ask to reselect the current favorite. If I 
give it classid and it is there, then run it. If not, then use the 
current default. If no defalut, run the fallback.

The most simple <object> is:

<object type='what/ever+xml'>
Sorry.You can't do what/ever+xml
</object>

The W3C browser gets the player for the MIME running then you can pass 
events and data between the host DOM and the plugin runtime. If no 
type handler, then the backup text would get displayed.
The default handler is the last installed/registered for that MIME. 
Now, the user can register by hand to some extent. It is fine that W3C 
browsers are making that process of helping show the user what types 
are registered and ways to select which to use as the default MIME 
handler much easier and maybe, with the help of plugin makers, even 
understandable.

> Note that users can disable or enable plug-ins on the fly already in 
> some browsers,

That is OK. Load a page. change the default. reload or new and hava a 
look. That is one way. There are other ways that do not follow the 
standards track.
Most important is when the user decides it is OK, then there are none 
or few of those choices to make and the show can proceed without 
further interruption.

> so it's not order of installation that ends up mattering here.

No problem until you get two competing applications for the same MIME.
A normal plugin installation should ask enough questions so that the 
user understands that the current installation will be the default 
handler for whatever types - in particular the 'standard' MIME types. 
If I say yes, that is my new default. If I end up not liking that 
choice, then hopefully there is simple way to reset that choice 
without absolutely needing to uninstall and reinstall. Again, the W3C 
browsers are showing some good stuff and I hope it improves even more 
so the user can actually dabble in MIMEs.

> In general, how a browser decides which of multiple plug-ins that 
> can all handle a type is used is up to the browser.

Hopefully the user has control of the browser so as to make the 
choices that may need to be made.
So I still see classid is an attempt to give tha author a tool. .

> 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...

Maybe more about q value is in order (like, how does it help?) but 
yes, web facing issues is on topic, I hope.
One is that the list of interfaces for <object> is missing classid 
along with a note about the global interfaces defined by the <param>s 
and other negotiation with the plugin. And also I am looking for 
HTMLObjectElement. Do you think that is a discussion for this list?

> -Boris

Thanks, Boris and Best Regards,
Joe

Received on Tuesday, 2 June 2009 03:56:41 UTC