Re: [css-transforms] transform-origin and SVG elements

Hi Cameron,

Sent from my iPhone

> On Oct 17, 2013, at 1:35 AM, "Cameron McCormack" <cam@mcc.id.au> wrote:
> 
> I think the behaviour of transform-origin, where lengths mean different 
> things depending on whether the element is an SVG element or not, isn't 
> great.  

This is not a new concern and we discussed this during the Hamburg F2F 2012.

I agree that it looks weird on the first view, but the problem is that percentage values relative to the viewport are not helpful for web authors at all. They want to rotate elements from the center or corner of an element or close by the corner. This is (now speaking as WebKit/Blink developer) exactly the use case that we see from web developers.

> It leads to questions like:
> 
> - Why shouldn't 'transform-origin: 0px 0px' and 'transform-origin: 0% 
> 0%' mean the same thing?  Surely 0% of anything is 0, and so that should 
> be equivalent to 0px.

No, as you said it is not the same in SVG. The one is from the coordinate origin, the other is from the figures top left (object bounding box top left).

For HTML both are always the same and therefore there is no such weirdness.

> 
> - How do we treat 'transform-origin: calc(0% + 0px) calc(0% + 0px)'?

I thought about this lately. The weirdness here is that calc() according to the spec is not aware of its usage and therefore doesn't know if it is a position or a dimension (to compare it with transform). And therefore does not know if it should be resolved according to the position of the obb or it's width/height. I do not think that this is actually the case. The percentage value is still resolved at the very end when we know about these details again and therefore can be treated according to the CSS Transforms spec. That said: it should be the top left of the figure.

> 
> 
> What about having something in the property value that explicitly opts 
> in to having values be relative to the SVG viewport rather than the 
> bounding box?  For example:
> 
>   transform-origin: viewport 50% 50%;  /* middle of the viewport */
>   transform-origin: 50% 50%;           /* middle of the bbox */
>   transform-origin: viewport 4px 4px;  /* relative to viewport origin */
>   transform-origin: 4px 4px;           /* relative to the bbox origin */
> 
> And then the UA style sheet could set
> 
>   transform-origin: viewport 0 0;
> 
> on SVG elements.

It is a reasonable approach but might confuse authors more than it actually helps IMO.

> 
> 
> Alternatively, since setting the transform origin to be anything 
> viewport relative except for the origin isn't that useful -- and could 
> be handled by translations in the 'transform' property -- we could just 
> add a single new value which means the viewport origin for SVG elements, 
> and the bbox origin for other elements:
> 
>   transform-origin: auto;
> 
> This would then be the initial value, no need for a UA style sheet rule. 
>  Percentages and lengths would always be relative to the bbox.

Again, you need to assume that people using CSS Transforms come from the HTML world. Every diverging does poison there understanding.

> 
> 
> Even if we don't do either of these, and leave the "percentages are 
> interpreted differently" behaviour, we should define what happens with 
> calc()s that contain percentages.
> 

As I said in one of the previous paragraphs, this is not necessarily needed. I need to check what browsers do currently.

Greetings
Dirk

Received on Thursday, 17 October 2013 04:58:31 UTC