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

I remember from past discussions in the FX Group that the “transform” attribute and “transform” property behave differently. At least for “transform-origin” it’s currently defined that way [1] . We originally decided that the CSS property will override the SVG attribute (which is how it works with current SVG I think).

People have commented to me that would like the current proposal changed such that CSS transform property is additive to the SVG transform attribute. That is, the CSS transform property will apply to SVG elements based on the bounding box of the SVG element with respect to the top-level document. This differs from the current proposal for the CSS transform property to override the SVG transform attribute. It resolves the syntax/parsing issue and makes sense in developer scenarios, particularly concerning animation.

One question that we need to answer with both options below is, what happens if the “transform-origin” is already specified on an SVG element? Does the UA style rule (1a) or the transform mapping (1b) override what is defined? Or do the value(s) of the “transform-origin” override the style rule/mapping?

Cheers,
Anthony

[1] http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html




From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Robert O'Callahan
Sent: Friday, 25 March 2011 4:01 PM
To: public-fx@w3.org; Jonathan Watt; Cameron McCormack
Subject: 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]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.