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

> Neither HTML4@declare nor HTML5@hidden/@declare  ...

First, is the html5 @hidden objective to hide some subtree of markup 
and content from rendering but have it exposed in the DOM as if it is 
being rendered?

>>>>>>> The hidden attribute is meant to mark a DOM subtree pruned 
>>>>>>> from all presentations on all media.

is that quote a base objective of this discussion? If so, the the 
functionality of of html40 <object> @declare may be realted.

>>> There should be no reason to doubt that the OBJECT in this example 
>>> would render if @declare was removed.
>>
>> [...] 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.

Yes Leif. You showed the first html40 example earlier.
[[
<P><OBJECT declare
        id="earth.declaration"
        data="TheEarth.mpeg"
        type="application/mpeg">
   The <STRONG>Earth</STRONG> as seen from space.
</OBJECT>
...later in the document...
<P>A neat <A href="#earth.declaration"> animation of The Earth!</A>
[[

html40 text:"Thus, the object can be activated by clicking on some 
highlighted text ...

Right, the <a> affects the declared object.
But, does href=#aname work with id? I think if you remove @declare 
then <object> would play on startup and <a> onclick would do default 
no valid target.

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

Here is what I am looking at for the second html40 example::
[[
<P><OBJECT declare
     id="tribune"
     type="application/x-webfont"
     data="tribune.gif">
</OBJECT>
[then elsewhere in the document] // added comment
...view the poem in KublaKhan.txt here...
<P><OBJECT classid="http://foo.bar.com/poem_viewer"
           data="KublaKhan.txt">
<PARAM name="font" valuetype="object" value="#tribune">
<P>You're missing a really cool poem viewer ...
</OBJECT>
[[

Not sure about 'canvas' in your description.
in the example, the first object would not be run. The second object 
would run at startup as if it was written as:

<OBJECT classid="http://foo.bar.com/poem_viewer"
      id="tribune" (?)
     type="application/x-webfont"
     data="KublaKhan.txt">
<P>You're missing a really cool poem viewer ...
</OBJECT>

and "poem_viewer" can talk to the host about some details shared with 
the declared object
.
I was thinking I could also elsewhere write:

<OBJECT classid="http://foo.bar.com/poem_viewer"
            data="XanaduandTed.txt">
<PARAM name="font" valuetype="object" value="#tribune">
<P>You're missing another because you have no foo.bar ...
</OBJECT>

and that one would play as if written as:

<OBJECT classid="http://foo.bar.com/poem_viewer"
      id="tribune" (?)
     type="application/x-webfont"
     data="XanaduandTed.txt">
<P>You're missing another because you do not run foo.bar ...
</OBJECT>

So overall, just a way to share some values bertween the declared 
object and other objects via <param> elements. The declared object is 
never rendered, but it must be somehow accessible to the same DOM with 
others that share its values. Yes, maybe all kinds of complications.

Back to the top quote about pruning:)
Could we think:
The html40 <object> using @declare is not considered for presentation 
by any media (unless clicked by @href=#id).
?

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

html40 <param> included @type in case the current <object> was 
different than @type of the declared object, so since no <object> 
@declare, then no obvious need for <param> @type.

>> The default [valuetype]
>> is "string" and is there any use to providing the valuetype="ref" 
>> option in <param>? REF specifies that @value 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.

Then the only reason html40 <param> has @valuetype=REF is the case 
when the @value string is to be treated as a URI.
html40 @valuetype is base CDATA that could be tuned for string or URI 
or idref.
Is a URI always a DOMString?

Thanks and Best Regards,
Joe

> > (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 16:25:24 UTC