... and suddenly, a wild "overflow" and "text-overflow" appeared.
> Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.
What I meant is that the CSS specification for the new CSS transforms Level 2 has a fixed transformation matrix and order in which the properties are applied - whereas legacy "transform: rotate() scale() translate() ..." did not do this, and therefore was overly complicated.
In the new specification the transform order does not matter, because the order in which "translate: ...", "rotate: ...", "scale: ..." and "offset: ..." are applied is specified and cannot be changed. See [1]
PS: I'm talking about CSS transforms level 2, not level 1. I assume you are talking about level 1. "translate: 13% 37%" is a property whereas "transform: translate(13%, 37%)" was the legacy method.
Personally, I prefer CSS transforms level 2, because they are implementable in an easy manner. Having to write a complex compositor isn't an easy task, especially on mobile.
Overflow is easy enough to deal with, text-overflow requires more work because it actually requires you have a model that matches the W3C specification understanding of generating boxes, instead of matching elements 1:1 which is what most naive implementations do. The same can be said about the white-space property.
Both are easy to implement; in one version, you parse then push the exact order of the parsed statements to matrix transformations. In level 2, you coerce them into the standardized order.
That being said, if you wanted to do anything based off of developer-specified transforms, you have to use level 1's style of applying the transformations. I would expect that GSAP and other such libraries rely on this behavior. Anyone familiar with shader-based transform code will be thinking in this manner anyway.
I'm not sure why anyone would want to use the level 2 manner of specifying transforms if you know what you're doing, because presumably, you immediately lose the ability to push additional transforms to the transform stack.
... and suddenly, a wild "overflow" and "text-overflow" appeared.
> Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.
What I meant is that the CSS specification for the new CSS transforms Level 2 has a fixed transformation matrix and order in which the properties are applied - whereas legacy "transform: rotate() scale() translate() ..." did not do this, and therefore was overly complicated.
In the new specification the transform order does not matter, because the order in which "translate: ...", "rotate: ...", "scale: ..." and "offset: ..." are applied is specified and cannot be changed. See [1]
PS: I'm talking about CSS transforms level 2, not level 1. I assume you are talking about level 1. "translate: 13% 37%" is a property whereas "transform: translate(13%, 37%)" was the legacy method.
Personally, I prefer CSS transforms level 2, because they are implementable in an easy manner. Having to write a complex compositor isn't an easy task, especially on mobile.
[1] https://drafts.csswg.org/css-transforms-2/#ctm