[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] ISSUE: what does 'get..' return?
Hi Lofton, I'll do my best to keep this email well formatted... <snip> >> Then my question is, what should be displayed in the following case: >> >> BEGAPS 'first' >> 'visibility' off >> BEGAPS 'second' >> ENDAPS; >> ENDAPS; >> >> Do we see 'second' or not? I want the answer to be 'second' is not >> displayed. LH> I agree, we do NOT want to see 'second'. But... Ok, I think we all agree on this. >> However, the spec as it is now, is underspecified and needs to be >> clarified. LH> Clarified perhaps, but I think it does what we want. 3.2.2.9 says: LH> Initial value: on LH> Applies to: layer, grobject, para, subpara LH> Inherited: yes LH> I understand this as meaning that 'second' is invisible -- the nearest LH> explicit setting on an ancestor node, 'off', inherits to its descendents, LH> overriding the "initial value". I.e., initial value only pertains if there LH> is not an explicit, inherited value set on an ancestor. After re-reading section 5.4 I agree as well. >> I would like for us to state that if 'visibility' or 'interactivity' >> is not specified, it's value is then 'inherit'. The CSS spec defines >> the 'inherit' property as: For a given element, the property takes >> the same computed value as the property for the element's parent. >> This would generate the result I'm looking for. LH> I'm reluctant to accept this yet, because I'm not sure it's needed. I LH> understand and agree with the effect that you want. But I think it's LH> already there in the spec. My proposal is based on the CSS initial value; yours, on the SVG initial value. For some reason (I don't know what it is), SVG adopted a different default value than CSS. LH> Your proposal also raises a question: if all elements in the LH> picture have 'inherit' initial value, then are they visible or LH> not? I.e., does every WebCGM instance have to explicitly set 'visible' LH> on the root element? Or do we have to invent some artifice to make the LH> value 'inherit', but make everything appear visible? This is a very minor issue, I'm sure it's somewhere in the CSS spec, I just couldn't find it. I haven't seen one HTML browser requiring <html visibility="visible"> in order for you to see the web page :-) LH> For comparison, I went looking at SVG11: LH> http://www.w3.org/TR/SVG11/painting.html#VisibilityProperty LH> Note that 'inherit' is a valid value, but the "Initial value" is 'visible', LH> and the attribute is inherited. Just like we now have in WebCGM. Like I said, you looked at SVG, I looked at CSS. >>If the group >> agrees with this, we then need to decide on something else... >> >> Should we allow to explicitly set 'visibility' and 'interactivity' >> to 'inherit? Yes or No? LH> Although I don't feel strongly, I can see the value, for a scenario like LH> this. Initially, everything is visible. A node X is set to LH> 'invisible'. Other stuff happens. Later on, we want node X to have the LH> same visibility as the branch of the tree it is in. Yes, we could use DOM LH> to go up the tree and find the first explicit setting on an ancestor. But LH> it would be easier to just set node X to 'inherit'. I don't really care what the initial value is, I care more about the final result. The more I think about it... I think we need section 5.4 to be re-worded a bit (nothing major). LH> On to Dieter's comments... LH> At 06:50 PM 4/27/2005 +0200, LH> =?us-ascii?Q?Dieter__Weidenbruck?= wrote: LH> [...] >>LH> >>LH> Let's consider the case of 'viewcontext' first. Section 3.2.2.2 says >>LH> "Initial value: none", which is reasonable. If I >>LH> getAppStructureAttr on an >>LH> APS where there is no explicit 'viewcontext' ApsAttr, then the answer >>LH> should be "undefined" (see side-issue about "undefined" below). >>LH> This is >>LH> the way DOM2 works, so we should stick with that unless we have a >>LH> compelling reason to deviate. >>3.1.2.4.2. defines a fallback behavior in cases where the viewcontext does >>not exist. We might consider to use the same fallback solution when >>doing a getAppStructureAttr on an APS without explicit 'viewcontext' >>attribute. LH> I'm no DOM expert, but I want to be very careful to go down this road, LH> because IMO it diverges from DOM (as well as from how SVG has done it). LH> It seems to me that we're potentially talking about two different things: LH> first, the Document Object -- a tree that is initially defined according to LH> DOM rules by data that occurs in the WebCGM document instance (+ XCF); and LH> second, a "viewer object", which tells us not about the WebCGM document but LH> about the viewed picture. I tend to agree with Lofton on this one. But it may turn out that users want what you are describing Dieter; but I think we should take a wait and see approach. <snip> -- Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]