I'm a layout implementor for Planimeter's Grid Engine. Implementing a naive subset of the algorithm for calculating the box sizes in the visual formatting model and calculating layout for normal flow, relative positioning, and absolute positioning is far easier to implement than flexbox.[1] There's nothing insane about this. And you'll learn even more when trying to draw to the screen.
Normal flow also doesn't require multiple passes, whereas flexbox does.[2] Even Yoga doesn't implement a conforming model.[3] I'd even speculate that flexbox performs slower than the standard visual formatting model just because of the differences in the algorithm.
Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.[4]
... 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.
I have not made any website or UI designs which require it, so I'm not experienced enough with it to say. As a result, I also have not made attempts to implement it.
c-smile is a well known implementor in the space, and his comments are valuable as well.
Normal flow also doesn't require multiple passes, whereas flexbox does.[2] Even Yoga doesn't implement a conforming model.[3] I'd even speculate that flexbox performs slower than the standard visual formatting model just because of the differences in the algorithm.
Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.[4]
[1]: https://github.com/Planimeter/grid-sdk/blob/master/engine/cl... [2]: https://www.w3.org/TR/css-flexbox-1/#resolve-flexible-length... [3]: https://github.com/facebook/yoga/blob/master/yoga/Yoga.cpp#L... [4]: https://docs.microsoft.com/en-us/dotnet/framework/winforms/a...