Re[2]: [cgmo-webcgm] XCF and "inherit" value

[Benoit Bezaire <benoit@itedo.com>]

Hi Lofton,

Ok we are getting close. There's a reason why the CSS specification
uses the word 'element' instead of 'node', and it's because a node is
not always an element (ex: text node, comment node, doctype node
etc...). Inheritance only applies to elements, not nodes.

So I'm a bit hesitant to start using the word 'node' or 'element' for
that matter. 'element' more or less implies XML syntax, which is not
the case here.

I disagree that Metafile is the root of the document. I think the
Picture is the root. Here's why:

i)   A root must be derived from the node class. This is not the case
for Metafile.
ii)  We currently say for 'parentNode': The parent (immediate ancestor
node of a node) of this node. All nodes, except WebCGMPicture may have
a parent.
iii) We get to the first picture via getWebCGMDocument().firstPicture,
not using firstChild.

So would you agree on the following wording?

"For the purposes of this inheritance model, Picture (the parent of
top-level APSs within the picture body) is treated like an APS and is
the root of the document tree."

-- 
 Benoit   mailto:benoit@itedo.com

 
Wednesday, May 25, 2005, 10:25:00 AM, Lofton wrote:

LH> First:  I agree that "inherit" should also be on 'layer'  (as you said,
LH> don't specialize an attribute-value set depending on the host element).

LH> Second:  I think we all agree what we want to happen for the top-level APS
LH> or 'layer'.  If it has the value "" (empty string, no set value) or
LH> "inherit", then it ought to take Initial Value.  What is unclear (to me at
LH> least) is what the inheritance-model wording currently says about it, i.e.,
LH> if/how 5.4 currently specifies that.  Because Picture and Metafile nodes
LH> are ancestors to the top-level APS within the picture.


LH> At 03:34 PM 5/24/2005 -0400, Benoit Bezaire wrote:
>>Hi Lofton,
>>
>>I'm catching up to emails... I've read the whole thread and I'm
>>replying only to this email. I don't think the problem is as
>>complicated as the thread seems to imply. See inline.

LH> No, I don't think it's particularly complicated, but ... if I was unable to
LH> determine the answer from 5.4, then that might indicate a problem for a
LH> naive reader (note, I'm not necessarily claiming to be non-naive!).

>>[...]
>>LH> Thoughts?  How can we deal with this cleanly?
>>To me, the thing seems quite simple and I doubt any changes are
>>required. Here's why?
>>
>>(i'm using markup, it's easier :)
>><metafile>
>>   <picture>
>>     <grobject visibility="inherit"/>
>>   </picture>
>></metafile>

LH> Let me make it simpler yet:

LH> <metafile>
LH>     <picture>
LH>       <grobject id="obj1" ... />
LH>     </picture>
LH> </metafile>

LH> This should have exactly the same effect as your example, right?  (And it
LH> doesn't force us to look at 5.4.2 -- handling of "inherit" value.)

LH> The problem is in 5.4.1.1, #2:  "Otherwise [if not explicitly set], if the
LH> style attribute is inherited and the Application Structure is not the root
LH> of the document tree, use the computed value of the parent Application
LH> Structure."

LH> I understand that you did a first-order adaptation of CSS2 wording (well
LH> done, at that!) and changed "element" to "APS".  To answer your question,
LH> No, Picture is not an APS, altho it sort of looks like one for some
LH> purposes.  (Nor is Metafile, which is the root according to figure 5.1b,
LH> and is where WebCGMNode.parentNode stops, presumably).

LH> So we need wording that allows the inheritance chain to continue up beyond
LH> the top-level APS, to the "root of the document tree".  Options:

LH> Opt.1:  s/APS/node/  ?  (Or in original CSS2, s/element/node/).
LH> Opt.2:  add at end of 5.4.1.1 something like, "For the purposes of this
LH> inheritance model, Picture (the parent of top-level APSs within the picture
LH> body) is treated like an APS, and Metafile (the root of the document tree)"

LH> Recommendation:  Opt.2.  Reason:  if those words had been present, I never
LH> would have asked the question in the first place.

LH> (Note.  We might want to add even more words, or an example involving
LH> 'visibility' or 'interactivity', the two affected attributes.)

LH> One last comment...


>>What is the value of visibility on the <grobject>?
>> From section: 5.4.1.1 Specified values,
>>"1. If the style attribute is assigned a value, use it."
>>Ok, simple enough... so we go to section 5.4.1.2 Computed values,
>>"See the section on inheritance for the definition of computed values
>>when the specified value is 'inherit'."
>>Ok, to section 5.4.2.1 The 'inherit' value,
>>"the property takes the same computed value as the style attribute for
>>the Application Structure's parent."
>>Here it doesn't really matter if you think there is a parent or not,
>>you will end up that you have to use the initial value, which is "on".
>>In both cases you will end up with "3. Otherwise use the style
>>attributes's initial value." of section 5.4.1.1
>>
>>BTW, this definition seems to work perfectly fine for HTML and SVG.
>>And I don't quite see what is the difference between my example above
>>and this:
>>
>><svg>
>>   <g visibility="inherit"/>
>></svg>
>>
>>The point is that when an implementation is doing the cascade, it
>>has no choice but to initialize it's style properties structure to the
>>Initial Values; those values are then cascaded down. So it doesn't
>>matter if you start at the <metafile> node, the <picture> node, or on
>>the <grobject> node... as soon as you see 'inherit', it will be
>>replaced by 'on' (the initial value).
>>
>>I tried to adapt the CSS wording to WebCGM when I first wrote it, and
>>it was me who replaced 'element' with 'Application Structure', which
>>may be introducing the question of "Is the picture node an APS?. I
>>think that's the only possible source of confusion on the matter. What
>>is a good replacement for 'element'?

LH> Yes, as 5.4.1.1, #2, shows, it is the specific use of APS that causes the
LH> problem, because ancestors of top-level APSs are not APSs.

LH> -Lofton.