- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 31 Jan 2010 02:37:46 +0100
- To: Joe D Williams <joedwil@earthlink.net>
- Cc: public-html@w3.org
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. s/realted/related > 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 Indeed. > and <a> onclick would do default no valid target. Don't understand: The <a> points to the same @id, regardless of the @declare. > 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. 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="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> 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 @hidden. > 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. [1] http://dev.w3.org/html5/spec/editing.html#the-hidden-attribute -- leif halvard silli
Received on Sunday, 31 January 2010 01:38:21 UTC