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

Joe D Williams, Sat, 30 Jan 2010 08:24:43 -0800:
>> 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?

That's what HTML5 says[1].  Btw, look how similar the usecases of HTML4 
and HTML5 are:

HTML5: "In the following skeletal example, the attribute is used to 
hide the Web game's main screen until the user logs in: 

HTML4: "It is possible to delay rendering of an object by first 
declaring the object (described below)."

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

Think so.

> If so, the the 
> functionality of of html40 <object> @declare may be realted.

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

<a href="#earth.declaration"> is pretty obvious: The answer is yes.  
(But perhaps I don't understand what you mean by "work with".)

> I think if you remove @declare then <object> would play on
> startup 


> and <a> onclick would do default no valid target.

Don't understand: The <a> points to the same @id, regardless of the 

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

I imagined that the poem would display at the locatin of the first 
OBJECT ... But I now see that your are right - it is the second object 
that fetches the resources from this object ... However, I think that 
this depends on the plug-in in question: It could simply decide when 
the declared object should display, rather than using as a resource.

> in the example, the first object would not be run.

But its image -  tribune.gif - would display (if @declare was removed). 
Or at least, the <object> would stop being semantically "hidden".

> The second object 
> would run at startup as if it was written as:
> <OBJECT classid=""
>      id="tribune" (?)
>     type="application/x-webfont"
>     data="KublaKhan.txt">
> <P>You're missing a really cool poem viewer ...

Ah, you seem right: It is the <object declare> element that is used as 
a resource for the poem. I believed it was the other way around ... 
(The key was to realize that KublaKhan.txt probably only contained one 
poem, rather than several poems ...) ;-)
> So overall, just a way to share some values between the declared 
> object and other objects via <param> elements.

Yes. HTML4: "When a document is to contain more than one instance of 
the same object, it is possible to separate the declaration of the 
object from its instantiations." 

Except when used to show/hide the element based on whether its fragment 
ID is targeted or not.

The sharing aspect is something that it conceptually shares with 

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

A declared object can be made visible by activating its id. Or? 
Whenever a second <object> governs the <object declare> element, then 
is it still possible to activate it via its link?
> 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).
> ?

Yes. (And a hidden feature that can be revealed by activatings its 
@href=#id isn't really hidden, one could claim. Although it is much 
simpler to use.)

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

I don't follow.

leif halvard silli

Received on Sunday, 31 January 2010 01:38:21 UTC