Re: <object> <param> was Object H:TML draft for FPWD consideration - object

Michael(tm) Smith announced:
>>  HTML: The Markup Language
>>  http://dev.w3.org/html5/markup/


Joe > In the text for <object> has @form been dropped?
>
> Is it reasonable to obsolete an item like @classid and then 
> recommend to put it into a <param> and expect it to be recognized 
> and acted upon by the host? For <object> could that possibly be 
> overloading <param> which is defined (exclusive?) as being sent to 
> plugin interfaces, opening for possible confusion with name-value 
> pairs used by both? Why does a plugin want to know what the author 
> used for @classid?


I think this is important in thinking about how <object> works. 
Mainly, the <param> name-value pairs should be in the runtime 
namespace represented by <object>, not in the host browser namespace 
for <object> attributes. To refine general operation of <object>, the 
<param>s should just be sent to the <object> context, not filtered by 
the host UA. For example, if a <param> such as
<param name='src' value='someuri'>
is used, the host should not recognize the <param>  as the same as 
@src for embed and go get the target and start sending it in, but 
instead just pass the string to the context as part of initialization 
and let the context issue a request when it wants to request it. Then 
values and operations of the standard <object> attributes can be 
accomplished and the <param>s can be left to the plugin to deal with.

This is especially important when HTML attributes have the same name 
string or are previously used common attributes, like @src in <embed>, 
and @classid. To me, it is OK for <embed> to have this indeterminable 
set of attributes that may operate in a very friendly way to plugins 
with the host UA sorting through and figures out what to send. And 
there will be authoring examples to show what to do and the 
author/user doesn't really have to worry which attribute is HTML 
syntax and which is plugin syntax.
But the standardized HTML interfaces for <object> and the UA operation 
with associated <param>s should be much more closely defined. That is, 
the authored @classid is certainly meant for the UA, not the context 
represented by <object>. Also since @classid is well implemented, it 
should not be obsoleted.

Especially if attributes are described in text of the standard, then 
they should be listed with other standard interfaces of the element. I 
believe that the plugin installer helper tools like @codebase are OK 
for <embed> because I believe that is where they originated. To keep 
them on the surface of <embed> will help plugins that are aligned with 
<embed>. However, for <object> I don't think these are needed because 
an author can produce a user-mediated installation process using 
<object> fallback.

This kind of hard to write a bug about because it is another overlap 
between <embed> and <object>.

Thank You and Best Regards,
Joe

Received on Thursday, 4 February 2010 22:35:58 UTC