12 messages in org.oasis-open.lists.cgmo-webcgmRe[2]: [cgmo-webcgm] ISSUE: what doe...| From | Sent On | Attachments |
|---|---|---|
| Lofton Henderson | Apr 27, 2005 7:10 am | |
| Benoit Bezaire | Apr 27, 2005 8:53 am | |
| Lofton Henderson | Apr 27, 2005 9:29 am | |
| Dieter Weidenbruck | Apr 27, 2005 9:49 am | |
| Lofton Henderson | Apr 27, 2005 11:13 am | |
| Benoit Bezaire | Apr 27, 2005 12:02 pm | |
| Benoit Bezaire | Apr 27, 2005 12:36 pm | |
| Dieter Weidenbruck | Apr 27, 2005 1:09 pm | |
| Benoit Bezaire | Apr 27, 2005 1:59 pm | |
| Dieter Weidenbruck | Apr 27, 2005 2:10 pm | |
| Lofton Henderson | Apr 27, 2005 2:59 pm | |
| Benoit Bezaire | Apr 28, 2005 6:09 am |
| Subject: | Re[2]: [cgmo-webcgm] ISSUE: what does 'get..' return? | |
|---|---|---|
| From: | Benoit Bezaire (ben...@itedo.com) | |
| Date: | Apr 27, 2005 12:36:11 pm | |
| List: | org.oasis-open.lists.cgmo-webcgm | |
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:ben...@itedo.com