Re: [csswg-drafts] [css-transforms] Let 'transform-origin' and 'transform' take comma-separated lists (#589)

I'm assuming that the commas in the `transform` property wouldn't have any other meaning / effect, other than grouping the transform sequence according to how they match to `transform-origin` (and `transform-box`, too!). In other words, if there was only a single value for the modifier properties, the series of function lists in the `transform` property would effectively get concatenated together, as if the commas weren't there.

That means that most of the time, commas in `transform` wouldn't have any effect, but they suddenly would if you also add a comma in `transform-origin`/`-box`.  I agree with Dirk's comment about the SVG syntax being fixed and independent, but it does add an extra layer of potential author confusion, if commas in the modifier properties _don't_ interact with arbitrary commas in the attribute, but _do_ interact with commas in the property value (which would often _seem_ arbitrary, until you change `transform-origin`).

A more serious complication: how would this interact with [the individual transform properties (`rotate`, `scale`, etc)](https://drafts.csswg.org/css-transforms-2/#individual-transforms)? Those also use `transform-origin` and `transform-box`, but wouldn't align neatly with the comma separated list pattern. Similarly, [`offset-anchor` for motion path](https://drafts.fxtf.org/motion-1/#offset-anchor-property) defaults to using the `transform-origin` value. I can't see any sensible way to integrate all these uses with this proposal.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/589#issuecomment-537659547 using your GitHub account

Received on Wednesday, 2 October 2019 20:10:49 UTC