transform and Style Property inheritance

[Lofton Henderson <lofton@rockynet.com>]

All --

 From the telecon minutes:

[[[
Action Item for Forrest to research how
this style property would be inherited
down through the tree.
]]]

I want to make a contribution to Forrest's action item.  It
is still needed to look at all of the stuff about Style Properties in 5.4
and 5.7.5, to make sure we're not missing something, and explain
'transform' properly:

[1]
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.html#L2666
[2]
http://www.w3.org/TR/2007/REC-webcgm20-20070130/WebCGM20-DOM.html#L5070

But I was looking and thinking, for example at a couple of items in
SVG.  Compare  'transform' attribute and 'stroke'
property:

[3]
http://www.w3.org/TR/SVG11/coords.html#TransformAttribute
[4]
http://www.w3.org/TR/SVG11/painting.html#StrokeProperties

Notice that the inheritance model is dealt with on 'stroke', but is
nowhere to be seen on 'transform'.  We shouldn't get hung up on the
attribute versus property naming thing here -- those are just
handles.  But looking at our previous emails, and the SVG sections
preceding [3], it is clear  now transforms should behave.

Whatever you call it, 'transform' does not inherit in the conventional
sense of WebCGM 5.4 [1].  E.g., give an object tree where A contains
B, which contains C and D:

APS-A
....APS-B
........APS-C
........APS-D  ,

then it is a reasonable concept that placing 'red' on A potentially
supersedes and redefines the color on B and C&D to red. 

But this is not how we think of transforms.  Placing a transform on
node A transforms all of the geometry within A, including the contents of
B, C, and D.  But it doesn't supersede any transform that might be
on B, C, and D.  It combines with them as we discussed and agreed in
earlier emails -- you post-multiply the matrix representations so that
the various contents in the tree are transformed as follows:

Ma -- inside APS-A, but outside APS-B.
Ma*Mb -- inside APS-B, but outside APS-C and APS-D.
Ma*Mb*Mc -- inside APS-C.
Ma*Mb*Md -- inside APS-D.

So the static-tree concepts of inheritance that are described in [1] and
in the "Common specifications" of [2] do not apply to
'transform', no matter what we call it.  We may have to add new
subsections to [1] and new stuff to [2], to make it clear how this new
'transform' Style Property behaves.

Furthermore, IMO, we definitely do NOT want any sort of controls on how a
'transform' SP on a node in the tree composes with ancestors or
descendants -- i.e., there is no sensible or useful analogy to 'inherit'
or 'no-inherit'.  Transforms in a static object tree behave and
combine in one simple way.

That said, we might well want a control on whether a DOM method that sets
a transform on a node in the object tree does it in 'replacement' mode or
'combine' mode.  But once that method has been executed, then there
is some well-defined transform on that node, and it combines with its
ancestors and descendants according to the usual rules.

I'm not close enough to the applications to say whether or not we want
such a replacement/combine control on the method.

-Lofton.