Re: <object> element

Hi Boris,

>>> 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?) ... 
>> .
>
> A q value would change the information the browser gets from the 
> plug-in about a MIME type from a binary value (support or not) to a 
> decimal value in the 0-1 range indicating how supported it is...  So 
> a plug-in could indicate "yeah, I can handle this MIME type, but not 
> very well" kind of things.  Not really related to HTML, but to the 
> internal APIs browsers use to talk to plug-ins.

That is interesting. Authoring and Delivery ratings?
I can see how a plugin might rate itself but how does the content 
declare how complex it is? For instance X3D has statements to tell 
level of capability required but the player doesn't know this until it 
loads the file and looks at some properties. Likewise the plugin can 
report its capabilities but you must ask some specific questions when 
it is already running. If the plugin fails or declines then it is 
probably late for the <object> fallback so recovery may get 
complicated. Actually the data in the content file are "Profile" that 
tells the basic level of features ranging from Interchange to Full, 
and "Component", like H-Anim, that brings in other structure and 
capabilities. But the plugin cannot report until it is running and the 
file info is not visible to the player until the file is loading.

Thanks and Best Regards,
Joe

Received on Tuesday, 2 June 2009 16:54:55 UTC