OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cgmo-webcgm] Style properties


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

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

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

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

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

Agreed.

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

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

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

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

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

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

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

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

However, IMO it would be perfectly consistent to define "Initial value:  100%" for all of them (except text-font).  It is a valid value of the style property, and it essentially means, "per whatever is in the CGM instance" (I.e., don't change/override the current values of the affected CGM attributes).

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

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

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

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

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

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

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

(to clarify ... that means its definition says "Inherited: yes", right?)

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

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

#1 is clearly, in my mind, a "Specified Value".  Is the value as determined by step #2 a Specified Value or a Computed Value or both?  Is the value as determined by step #3 a Specified Value or Computed Value or both (or...)? 

In a previous example you said, "'three' does not have a specified value, so it inherits the 'computed value' of ..."

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

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

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

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

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

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

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

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

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

A.) If the Computed Value of a style property involves "convert to absolute",
B.) and if we inherit the Computed Value,
then .... it creates problems for CSS2-like inheritance of style properties. 

Let's explore each of A and B:

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

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

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

B--inherit CV or SV:
-----
I'm wondering if we're getting trapped by trying to adhere to closely to CSS2.  Note CSS3 (WD) says,
http://www.w3.org/TR/2002/WD-css3-cascade-20020219/#inheritance ,
"As a general rule, it is the computed value of a property which is inherited. Properties may, however, specify that other sorts of values should be inherited instead."
So we could say, for step 2 of style property inheritance above, that the Specified Value is inherited (no problem with having to worry about the presence of 'inherit' value in the SV).  (In this case, there is still a problem defining what we mean by the CV of stroke-weight, if we have to convert 50% to absolute NVDC at the CV stage.)

Thoughts on this?

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

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

Can both model be combined into one?

Maybe. 

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

-Lofton.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]