[css-transforms-1] transform-origin: 0% not equivalent to 0px is confusing

[smfr]

https://www.w3.org/mid/525F2287.8050002@mcc.id.au

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. 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.

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

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.

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.

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.

[css-meeting-bot]

The CSS Working Group just discussed transform-origin: 0% != 0px, and agreed to the following resolutions:

RESOLUTION: no need to change anything for this issue. implementations just need to support transform-box

The full IRC log of that discussion

<dino> Topic: transform-origin: 0% != 0px
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/895
<dino> dbaron: it's only different for SVG?
<dino> smfr: yes
<dino> ChrisL: it's not that crazy to have the UA stylesheet do different things for SVG and CSS
<dino> Github Issue: https://github.com/w3c/csswg-drafts/issues/895
<dino> dbaron: it's only different for SVG?
<dino> smfr: yes
<dino> ChrisL: it's not that crazy to have the UA stylesheet do different things for SVG and CSS
<dino> smfr: auto is one proposal. or a keyword 'viewport'
<dino> Rossen: i'd prefer 'auto' as a magic keyword. And this might be our only option.
<dino> Rossen: other comments?
<dino> TabAtkins: I like 'auto'
<dino> TabAtkins: proposal is that the current 0% becomes 'auto', and then we change 0% to be the same as 0px
<dino> smfr: so 'auto' would be different for CSS and SVG?
<dino> TabAtkins: I don't care about that as much as having 0% and 0px using the same base.
<dino> transform-origin will now accept an 'auto' value which will be the initial value. For CSS, that is equivalent to 50% 50%. For SVG, it's equivalent to 0px 0px. And, from now on, in SVG, % are in the same base as px, so relative to the element.
<dino> <discussion of what % means for CSS properties in SVG>
<dino> ChrisL: I want to make sure that we're not clipped to 0-100% for CSS in SVG stuff.
<dino> dino: definitely not for transform-origin
<dino> smfr: there is also a proposal for transform-box, which would affect what % are resolved against
<dino> smfr: this is in level 1, but i'm not sure there are implementations
<dino> birtles: we implemented it
<Rossen> dino: if we all implement the box values there is no need have the percentages change
<birtles> Gecko intent to ship has some background: https://groups.google.com/forum/#!topic/mozilla.dev.platform/ssV6H4_3WGU
<dino> s/box/transform-box/
<dino> birtles: Blink has it implemented behind a flag
<birtles> Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=595829
<dino> proposed resolution: no need to change anything for this issue. implementations just need to add transform-box, or behave as if you do implement it
<dino> RESOLUTION: no need to change anything for this issue. implementations just need to support transform-box
<BogdanBrinza> Edge doesn't have plans for (at least) next release or two since we don't support CSS transforms on SVG boxes yet, so the problem doesn't exist for us
<dino> smfr: so we think that heycam's comments are all addressed by transform-box
<dino> dbaron: yes
<TabAtkins> ScribeNick: TabAtkins

[smfr]

I don't think this issue covers anything that's not covered by issue 857.