Re: ISSUE-95 hidden - Chairs Solicit Proposals - off topic object

Joe D Williams, Fri, 29 Jan 2010 19:02:37 -0800:

>> There should be no reason to doubt that the OBJECT in this example 
>> would render if @declare was removed.
> 
> Right. Of course, but then the instance requested in the <a> would 
> never appear? Or would the <a> work and <object> be available both 
> places? With no declare, I think the <a> should fail (do nothing 
> because no valid href target).

Neither HTML4@declare nor HTML5@hidden/@declare would affect the 
validity of the href target - the @id of the <object> is unaffected by 
@declare!  And the <object> would only be "available" at one location, 
namely where the <object> is. The <a> only causes the <object> to 
instantiate. 
 
> Same in second example. If you undeclare what I might call sort of 
> the object prototype, then it, or its fallback if not enough info, 
> should likely appear,  and the instance(s) may fallback due to 
> lack of some info or otherwise.  Me not know:)

In the second example, then the first <object> represents some kind of 
canvas. If you remove the @declare of the first <object>, then it - the 
canvas - would become visible. It doesn't have any fallback, though, 
because it is, after all, only a canvas. 

(It is of course interesting that this first <object> is designed so 
that it would not cause any harm if the UA doesn't support the @declare 
attribute! And it could be that even in the first example, where the 
OBJECT is instantiated from an <a>, it is meant that the animation of 
the earth doesn't start to roll automatically, but that the animation 
has to be started via a button.)

The second <object> of the second example should be entirely unaffected 
by the (lack of) presence of @declare in the first <object>. In case 
the UA doesn't support the plug-in of the second <object>, then a UA 
with support for @declare would not display the first <object> - but 
would instead display the fallback of the second <object>. An UA 
without support for @declare would display both.

I believe the HTML4 examples reveal the following things about the 
HTML4 attribute vs. the HTML5 spec draft attribute:

1) HTML5 spec draft attribute is scriptable, but not automatically 
interactive: A link pointing to the @hidden element would become 
"followed" - but without revealing the <object> - unlike @declare in 
HTML4, where it would be revealed.
2) For the HTML5 spec draft attribute, then CSS has no effect on 
whether it is presented to users or not. Whereas the HTML4 examples 
seem to hint, that the following two CSS rules describe an essential 
part of how @declare is meant to work:

		object[declare]{visibility:hidden;display:none /*?*/ ;} 
		object[declare]:target{visibility:visible;display:inline-block;}

> However, it is an interesting example of how <object> could work and 
> pass parameters. Also shows param with three attrs.
> <PARAM name="font" valuetype="object" value="#tribune">

Today we would have solved the font issue differently - via CSS - I 
suppose.

> I think it would be the wrong reason to drop @datatype

I gather you meant @valuetype. 

> and @type from 
> <param>  if it was thought to be only used with declare.

Agree.

> The default 
> is "string" and is there any use to providing the valuetype="ref" 
> option in <param>? REF specifies that the string should be treated as 
> a URI. Plugins use <param> to hold resource URL but always that I 
> have seen as just a string. Is being able to interpret @value as a 
> URI rather than a string important now? 

I agree that @valuetype="ref" looks less necessary.

> If so, then is @type in  <param> usable?

Don't know. But @valutype="ref" means that we can forget everything 
about MIME type - the URI wouild work in a way that only the plug-in 
knows about, which should be good enough.
-- 
leif halvard silli

Received on Saturday, 30 January 2010 11:29:05 UTC