Re[2]: [cgmo-webcgm] Style properties

[Benoit Bezaire <benoit@itedo.com>]

See inline...

Monday, May 16, 2005, 7:35:02 PM, Lofton wrote:

LH> Sorry this turned into such a long reply.  It is a difficult
LH> topic, partly because we're layering style properties over the CGM
LH> attribute model.  Although there isn't a perfect match, it is
LH> possible to define a sensible mapping. 

LH> The trouble comes when we try to adhere as closely as
LH> possible to the CSS inheritance model.  We have to bend it
LH> some where.  I have seen two possibilities:

LH> 1.) bend the definition of Computed Value, for style properties;
LH> 2.) or, bend the definition of what's inherited -- Specified Value
LH> instead of CV

LH> More (too much!) detail embedded....

LH> At 02:28 PM 5/9/2005 -0400, Benoit Bezaire wrote:
LH> [...]
LH> First, lets rename 'style attributes' to 'style properties', sinceCGM
LH> already has the concept of 'APS attributes' (ex:screentip).

LH> Agreed.
Ok. So this is solved.

LH> I think we all understand/agree that 'visibility' and 'interactivity'
LH> are 'APS attributes' not 'style properties'. Right?

LH> Only the DOM defines 'style properties', they are not part of theCGM
LH> file format. The 'style properties' we have defined so far are:
LH> background-color, character-height, fill-color, intensity,
LH> stroke-color, stroke-weight, text-color, text-font,raster-intensity.

LH> (As a side issue, let's remember to revisit text-font.  I do
LH> recall something from earlier, like we decided to remove it.)
I agree.

LH> The problem we are facing is that both 'style properties' and some APS
LH> attribute ('visibility'   'interactivity') require an inheritance
LH> model. We agreed that:

LH> BEGAPS 'one'
LH>   ATTR 'visibility' 'on'
LH>   BEGAPS 'two'
LH>   ...
LH>   ENDAPS;
LH> ENDAPS;

LH>  - 'two' would be visible, and
LH>  - example; settingone.setStyleAttr("intensity","50%") would make
LH>  'two' have an intensity of 50%.

LH> In my opinion, the inheritance model for both the APS attributes and
LH> style properties are similar with one exception: style properties do
LH> not have an 'Initial Value'. Note: Lofton may or may not agree with
LH> me, I'm not sure on what we agree on yet.

LH> They do not have an initial value that is inherent or
LH> explicit in the WebCGM instance (since they are not CGM attributes).

LH> However, IMO it would be perfectly consistent to define
LH> "Initial value:  100%" for all of them (except text-font).  It is
LH> a valid value of the style property, and it essentially means,
LH> "per whatever is in the CGM instance" (I.e., don't change/override
LH> the current values of the affected CGM attributes).
I'm not sure it is that simple. I'm not convinced (yet) that
100% as initial value is fine for all of them. Another problem I see,
is that in CSS there's a Applies To: notion, which we don't have. I
don't think it is possible to define an inheritance model without
specifying the Applies To:.
Example 1: what does it mean to have 'background-color' set to 100%?
What does this map to in CGM? And does it have an implied value?

Example 2: what does it mean to have 'stroke-weight' set to 100% at
the Picture level when the first instance of LINEWIDTH in my CGM file
is one line above a LINE primitive (i.e., LINEWIDTH is not found under
BEGPIC or BEGPICBODY; but BEGAPSBODY;)?

Does WebCGM clearly define on what LINEWIDTH applies to and where can
it legally be specified in the CGM file?

LH> A value of a DOM style property has a well defined mapping to
LH> CGM attribute values.  E.g., 100% stroke-weight on an APS
LH> implies current value of line-width and current value of edge-width
LH> for the stuff within the target APS (current value of these two CGM
LH> [primitive]attributes is well-defined everywhere in the WebCGM
LH> instance, by ISO CGM rules.)

LH> The current wording of section 5.4 came from the CSS specification
LH> which I then tried to adapt to WebCGM (and apparently did a poorjob,
LH> sorry) is this (5.4.1.1 Specified values):

LH> User agents must first assign a specified value to each style
LH> attributes based on the following mechanisms (in order of precedence):

LH> 1. If the style attribute is assigned a value, use it.
LH> 2. Otherwise, if the style attribute is inherited and theApplication
LH> Structure is not the root of the document tree, use the computedvalue
LH> of the parent Application Structure. 
LH> 3. Otherwise use the style attributes's initial value. The initial
LH> value of each property is indicated in the style attribute's
LH> definition.  

LH> Here's an attempt at rewording the above for 'visibility' and
LH> 'interactivity' only.

LH> When reading a WebCGM file, (or following a change in APS attribute
LH> values from a DOM method to 'visibility' and 'interactivity',) User
LH> Agents must assign a specified value for those APS attributes basedon
LH> the following mechanisms (in order of precedence):

LH> 1. If the APS attribute is assigned a value, use it.
LH> 2. Otherwise, if the APS attribute is inherited 

LH> (to clarify ... that means its definition says "Inherited:yes", right?)
Yes, that is correct.

LH> and the Application
LH> Structure is not the root of the document tree, use the computed value
LH> of the parent Application Structure. 
LH> 3. Otherwise use the APS attribute's initial value. The initial value
LH> of each APS attribute is indicated in APS attribute's definition.

LH> I don't mean to backtrack or nitpick, but I have a question. 
LH> In the paragraph before the 1-3 list, it says "UA must assign a
LH> specified value for those APS attributes".  Which implies that
LH> steps 1-3 are how the specified value is determined.
Yes.

LH> #1 is clearly, in my mind, a "Specified Value".  Is the value
LH> as determined by step #2 a Specified Value or a Computed Value
LH> or both?
Specified, but the Computed Value will likely result in the same
value.

LH>   Is the value as determined by step #3 a Specified Value
LH> or Computed Value or both (or...)? 
Specified, but the Computed Value will likely result in the same
value.

LH> In a previous example you said, "'three' does not have a
LH> specified value, so it inherits the 'computed value' of ..."
True, it didn't have a specified value per se on the APS, so the User
Agent has to compute one.

LH> [...later addition...]  I just went and checked CSS:
LH> http://www.w3.org/TR/CSS21/cascade.html

LH> Altho' it is counter-intuitive to me, indeed each of the
LH> values as determined by steps 1-3 is a Specified Value.  So
LH> yesterday, in your example, we should have said something like,
LH> "'three' does not have an explicitly assigned value in the CGM,
LH> so..."  ?  (I guess I answered my question.  The steps 1-3
LH> correctly define SVs, but we were careless with terminology in the
LH> example.)
Yes, we are on the same page.

LH> Summary.  For 'visibility' and 'interactivity', Specified
LH> Value is the same as Computed Value (unless SV is 'inherit', in
LH> which case CV is 'on' or 'off', as determined by inheritance). 
LH> Right?
Yes.

LH> Now if I attempt to define the inheritance model for the 'style
LH> properties' I get something like this:

LH> Following a change in APS style property values from a DOM method,
LH> User Agents must assign a specified value for the given style property
LH> on the given node and its children based on the following mechanisms
LH> (in order of precedence): 

LH> 1. If the APS is assigned a style property value, use it.
LH> 2. Otherwise, use the computed value of the parent Application
LH> Structure. 

LH> In my opinion, what is still undefined is the computed value of a
LH> style property (ex: stroke-weight).

LH> Good question.  By the existing definition of "Computed value"
LH> (see 1st pgph of 5.4.1.2), it says to turn relative units(e.g., %)
LH> into absolute units (e.g., NVDC).  As the stroke-weight example
LH> shows, we cannot do this at the APS level (we have to do it at the
LH> graphical primitive and attribute level within the body of the
LH> APS, for each of line-width and edge-width).

LH> Btw, do we have a contradiction within 5.4?  The 1st pgph of
LH> 5.4.1.2 says, "[computed values] ... for example relative units (%)
LH> are computed to absolute values (NVDC)."  But the 2nd pgph of
LH> 5.4.1 says, "...then resolved into a value that is used for
LH> inheritance(the computed value), then converted into an absolute
LH> value if necessary(the used value), then..."  [...later
LH> addition... I just checked CSS2 -- same confusing overloading of
LH> the term "absolute" there.]
I don't see the contradiction, could you explain.

LH> A.) If the Computed Value of a style property involves "convert to
LH> absolute",
LH> B.) and if we inherit the Computed Value, 
LH> then .... it creates problems for CSS2-like inheritance of style
LH> properties.  
What are these A) and B)? I'm not sure I'm following your line of
thoughts here?

I'll stop here for now, there's no point continuing if I'm lost.
Lofton, can we try to work with a number of small precise emails
(i.e., small precise problems). It won't be easy to workout this issue
with such long emails.

Would you mind replying to my comments above, once we've agreed on
those we can move on the rest of the email.

Cheers,

-- 
 Benoit   mailto:benoit@itedo.com

 
LH> Let's explore each of A and B:

LH> A--when to "convert to absolute": 
LH> -----
LH> To me, it is not necessary to convert to absolute before Used
LH> Value --everything before is concerned with inheritance, and
LH> consideration of display begins at Used Value.  I think "convert
LH> to absolute" has more to do with display than inheritance.

LH> But ... I may be doing violence to the CSS2 model here? 
LH> [CSS2 seems pretty clear that it wants you to convert things like %
LH> at the CV stage.]

LH> If we postpone "convert to absolute", then conceptually
LH> there is no problem with defining Computed Value (it's the same as
LH> Specified Value, since the value 'inherit' is not a valid value for
LH> style properties), and there is no problem with defining an Initial
LH> Value(100%) for the style properties.  Then you can add step 3 to
LH> the style properties inheritance model.

LH> B--inherit CV or SV:
LH> -----
LH> I'm wondering if we're getting trapped by trying to adhere to
LH> closely to CSS2.  Note CSS3 (WD) says,
LH> http://www.w3.org/TR/2002/WD-css3-cascade-20020219/#inheritance,
LH> "As a general rule, it is the computed value of a property which
LH> is inherited. Properties may, however, specify that other sorts of
LH> values should be inherited instead." 

LH> So we could say, for step 2 of style property inheritance
LH> above, that the Specified Value is inherited (no problem with
LH> having to worry about the presence of 'inherit' value in the SV). 
LH> (In this case, there is still a problem defining what we mean by
LH> the CV of stroke-weight, if we have to convert 50% to absolute
LH> NVDC at the CV stage.)

LH> Thoughts on this?

LH> This would work, for style properties, and doesn't require
LH> contra-CSS2 determination of CV:

LH> Assign a specified value for each style property for each APS as follows:
LH> 1. If the APS is assigned a style property value, use it.
LH> 2. Otherwise, if the APS is not the root of the document tree,
LH> use the *specified* value of the parent APS.
LH> 3. Otherwise, use the initial value.  [They would all be 100%].

LH> Can both model be combined into one?


LH> Maybe.  

LH> But let's sort 'em out separately first.  Particularly these
LH> questions for style properties of Computed Value, which value
LH> inherits (CV or SV), and Initial Value.  

LH> -Lofton.