-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-transforms] Let 'transform-origin' and 'transform' take comma-separated lists #589
Comments
How would |
To the counter-argument of comma-separation and backwards compatibility with SVG
In other words, we decoupled the syntax of the |
I'm assuming that the commas in the That means that most of the time, commas in A more serious complication (as Eric noted): how would this interact with the individual transform properties ( |
At the time I created this issue the CSS properties didn't exist yet. 😄 A more complex approach would be to also extend those to take lists of transformations. Note that my initial suggestion for the changed syntax for Sebastian |
I just saw @AmeliaBR's comment after I posted my one. Thank you for pointing out Regarding the comma separation issue, yes, in CSS it's meant to match the different values within the modifier properties with each other. The logic would be similar to the one for layering multiple background images, i.e. the number of transforms is determined by the number of comma-separated functions in the transform-function: scale(2), rotate(30deg), translateX(100px);
transform-origin: center center, 100px 0; transform-function: scale(2), rotate(30deg), translateX(100px);
transform-origin: center center, 100px 0, center center; It's very unfortunate that in SVG there is generally no difference between space and comma separation and I agree that this may cause some confusion for authors. What relates to Sebastian |
Ideally this would affect how animation works, specifically by bounding the sequences that get glommed together into a matrix() when there's a function mismatch.
Agreed, having them as part of the first transform-group makes the most sense to me. |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: Let 'transform-origin' and 'transform' take comma-separated lists<dael> github: https://github.com//issues/589 <dael> smfr: Old proposal to allow transform property tot ake a comma sep list where each has its own transform-origin. Additionally a proposal for shorthand to allow origins <dael> smfr: Seems a bit too late to add this, big change to transform. Not in favor, but welcome other input <dbaron> Seems like a bunch of complexity (e.g., with animations), so I'm fine with rejecting the proposal. <dael> TabAtkins: Reasonable. To address use case might be interesting to expore transform-origin function that takes the list. But that would be convenience feature. <dael> TabAtkins: I was in favor back in the day, but I agree it's minor and not worht the churn <dael> AmeliaBR: Agree with TabAtkins . If we do this it has to apply to transform-box as well as transform-origin <dael> astearns: Is what the proposal requests possible but in a different way? <dael> TabAtkins: Yeah, transalte-origin is a translate function before and after your transform list. You can simulate it on your own. You have to know how to do that and perhaps an example would be good. Nothing to prevent you from representing on your own <dael> astearns: Proposal is to reject this proposal <dael> astearns: Concerns? <dael> RESOLVED: Reject this proposal |
Closing per WG resolution. |
In the meeting notes @tabatkins said that "translate-origin is a translate function before and after your transform list". I guess he still referred to He also mentioned that there should be an example added explaining that. It would be good to see how you do a scaling around the center and then a rotation around the bottom right corner of the scaled element, for example. Sebastian |
Yes, that should be
is equivalent to
See steps 2 and 8 in https://drafts.csswg.org/css-transforms-2/#ctm |
And if you want to scale from the center-left but rotate around the middle, it would look something like: transform-origin: 0 0; /* reset to have no effect on the math */
transform: translate(0, 50%) scale(4) translate(0, -50%)
/* scale around center-left */
translate(50%, 50%) rotate(45deg) translate(-50%, -50%)
/* rotate around center */; |
Yup, 'translate-origin' is nothing more than a shorthand for a (And so, on the call I floated the idea of a |
Excuse the long delay for my reply and thank you very much for your explanations! This was not clear to me at all before. Because I'm surely not the only one, I've now added a simple example explaining that to the MDN page for Regarding my example, I still believe transform-origin: center, bottom right;
transform: scale(2), rotate(45deg); is way more readable than transform-origin: 0 0;
transform:
translate(50% 50%) scale(2) translate(-50% -50%)
translate(100% 100%) rotate(45deg) translate(-100% -100%); Though I can understand that the use case is probably not strong enough to adjust existing implementations to the more complex list syntax. Sebastian |
Previous discussion
Back in 2012 there was a discussion about extending the
transform-origin
property to take a list of origins and maketransform
comma-separated.I'd like to reconsider this, because I think its a common use case to have different origins for transformations and I couldn't find a final conclusion on this.
The suggestions in that thread were:
transform-origin
andtransform
take comma-separated lists like e.g. thebackground-*
properties.origin()
function affecting all following transformationsArguments against the different solutions above were:
Proposal
Considering the above, my idea is the following:
Introduce a
transform-function
longhand property, which takes a comma-separated list of multiple space-separated transform functionsThe syntax of
transform-function
would look like this:where
Change
transform-origin
to take a comma-separated list of transform originsThe syntax of
transform-origin
would then look like this:where
(or maybe just
<position>
)Each would default to
50% 50%
.Turn
transform
into a shorthand fortransform-function
andtransform-origin
The syntax of
transform
would then look like this:This would be backwards compatible, make them consistent with other properties like
background-*
, avoid confusion and allow to set different origins for the transform functions.Example
This would rotate the element by 20 degrees around the upper-left corner, then skew it by 10 degrees on the X axis and 5 degrees on the Y axis, and finally scale it around the center by 80 percent.
Sebastian
The text was updated successfully, but these errors were encountered: