[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[3]: [cgmo-webcgm] XCF and "inherit" value
Thursday, May 26, 2005, 12:39:51 PM, Lofton wrote: LH> Hi Benoit, all -- LH> Close, but not quite there yet... LH> Benoit, of course I want your answers to my questions (below). But I'd LH> also like to hear some other TC opinions. Same here... LH> At 08:55 AM 5/26/2005 -0400, Benoit Bezaire wrote: >>[...] >>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. LH> Okay, I have no strong opinion here. (Actually, "element" is overloaded in LH> the WebCGM context, because ISO CGM uses "element" for any individual CGM LH> command -- primitives, attributes, delimiters, controls, etc.) >>I disagree that Metafile is the root of the document. I think the >>Picture is the root. LH> I have some problems with this suggestion, to resolve before I can LH> agree. One problem is... LH> Look at Example 5.1a, the paragraph after the box (which you wrote) LH> says: "The in-memory tree representation of this illustration should be LH> similar to the illustration found below. It is a simple tree structure with LH> a root element WebCGMMetafile, one of the children of the root is a LH> WebCGMPicture; the WebCGMPicture contains a Layer and the layer contains an LH> Application Structure of type grobject." Doh! I wrote that section in the "Once upon a time..." timeframe (i.e, a lonnnng time ago). Yes, if we say that Picture is the root, the graphic and that wording has to change. LH> Plus, the figures imply that the metafile is the root. Of the document tree. >>Here's why: >> >>i) A root must be derived from the node class. This is not the case >>for Metafile. LH> I don't understand this statement. Explain please? Look at the IDL snippet, you'll see that: interface WebCGMAppStructure : WebCGMNode ... interface WebCGMPicture : WebCGMNode ... interface WebCGMMetafile ... (doesn't derive from WebCGMNode). As soon as a class derives from WebCGMNode, it inherits the parentNode/firstChild functionality. WebCGMMetafile does not derive from WebCGMNode. This is one of the reason why I say that the Picture is the root. >>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. LH> Aha, I had missed that, and one of my major objections was that I thought LH> WebCGMPicture *could* have a parentNode (which the root cannot). LH> [Btw, editorial, in the sentence, "All nodes, except WebCGMPicture may have LH> a parent.": s/may// , correct?] False... but it should be "All nodes, except WebCGMPicture and WebCGMAttr may have a parent." >>iii) We get to the first picture via >>getWebCGMDocument().firstPicture, >>not using firstChild. LH> Yes, that is also how I wrote my test cases (in copycat style). LH> But on the other hand, look at the first paragraph of 5.7 and the one-line LH> descriptions of the node types, after "WebCGM has the following node types LH> and children". That certainly creates the impression that Picture(s) are LH> children of Metafile. I agree that it does. >>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." LH> I'm in favor of something like this, but: LH> 1.) I want to clarify the questions I asked above. LH> 2.) I want to be sure, if we make such a definition, that we're not somehow LH> shooting ourselves in the foot, for adaptation of 2.0 DOM to multi-picture LH> metafiles. (I don't see a specific problem yet. Does anyone else?) The deprecated multi-picture feature seems to be the source of the problem here. You have to admit that having both Metafile and Picture is a waste... they could be combined into one. LH> Finally, if we go that way ... there is text to be cleaned up in several LH> places, right? I see three possible solutions: A) Make Metafile the root: requires for Metafile to derive from Node. B) Make Picture the root: requires editorial work. C) Remove Metafile interface: could cause some problems for addEventListener() and deprecated multi-picture metafile. I don't like either options. They all seem to be a lot of work. It would be nice to hear from others on this... you and I don't seem to be able to find a nice quick fix. -- Benoit mailto:benoit@itedo.com LH> Regards, LH> -Lofton. >>-- >> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]