Some practical issues integrating the SVG transform attribute with CSS transform properties

I assume we want to make the SVG 'transform' attribute a presentational
attribute that maps onto the CSS 'transform' property. A few issues have
come up, and many of them will apply to other attributes that we map up to
CSS, so they're worth discussing.

1) Elements with SVG transform attributes must default to top-left as their
transform origin, but CSS transforms default to the center. Here are two
options for resolving this:
1a) Introduce a UA style rule that sets transform-origin to "top left" for
all SVG elements.
1b) Make the "transform" presentational attribute map the CSS
transform-origin property to "top left".
1b makes setting CSS 'transform' on an SVG element consistent with non-SVG
elements; the element rotates around its center by default. But it makes
setting the "transform" attribute on an SVG element different from setting
the CSS "transform" property on the element; the former sets
transform-origin but the latter does not. 1a is the other way around;
setting the SVG "transform" attribute would behave consistently with setting
the CSS "transform" property, but setting CSS transforms on an SVG element
would behave differently to an HTML element, by default. Which consistency
is more important? I propose choosing consistency between the "transform"
attribute and the "transform" property, option 1a.

2) What is the behavior of the SVG 'baseVal' API?
I think 'baseVal' should always reflect and affect the attribute value only.
So it would not by affected by inline style or any other CSS styling. I
can't see any other option making sense.

3) What should SVG 'animVal' reflect? Here are a few options:
3a) 'animVal' returns the animated attribute value as set by SMIL if there
is one, otherwise the baseVal. It does not reflect any CSS styling,
including any CSS transitions or animations, nor does it reflect any CSS
values animated by SMIL.
3b) 'animVal' returns the animated CSS value as set by SMIL if there is one,
otherwise the animated attribute value as set by SMIL, otherwise the
baseVal. It does not reflect any other CSS styling, including any CSS
transitions or animations
3c) 'animVal' returns the CSS computed value, including CSS transitions and
animations, and the effects of any CSS rules overriding the style.
I suspect 3c is most intuitive for authors. However, there is a problem:
unlike attribute values, CSS computed style changes happen at unpredictable
times, often asynchronously, and can be coalesced, and we don't want the
presence or absence of coalescing to be observable via the identity of
transform objects in the animVal list.

For example, consider the case where the computed transform style starts
with one matrix, changes to 'none', then changes back to the same matrix ---
but depending on how coalescing happens in the style system, the
intermediate state might not happen so that the value never really changes
at all. Should the SVGMatrix object in the animVal list to be the same
object before and after that sequence? Either it always should be or it
always shouldn't be. Making it always not the same object would basically
require animVal to return new objects each time an item in the list is
requested, which is wasteful. So we should make it always return the same
objects. That means we have to be careful about keeping objects around when
the list length reduces, and reusing those objects if the list length
increases again.

4) As we extend CSS z-index to SVG, should SVG transforms induce stacking
contexts on their elements, like CSS transforms do?
I don't know of any use-cases that would be adversely affected by doing
this, so I think for consistency the answer should be yes.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]