Re: [csswg-drafts] [css-transforms-2] proposal: new "transform: bend();" function (#6293)

For what it's worth, the axes in the initial proposal don't seem to correspond with the x-, y- and z-axis we have in the other transform functions.

What's shown in the `bendX()` and `bendY()` example actually bends around the z-axis (pointing "into the monitor"). So, `bendZ()` seems to be the one that actually covers the use cases mentioned, i.e. a circular progress bar and a pie or donut chart.

Bending along the x-axis means to rotate the top and/or bottom edge of the element into the screen. And bending along the y-axis applies the same to the left and right axis.
That means, the element would appear smaller in one axis and clinched towards the edges.

Also, the examples of 180° and 360° bending in the initial proposal indicate that the edges would collapse at 0°, which they obviously don't do. So it would need to be defined how exactly the bending works.
Furthermore, it needs to be expressed how it interacts with `transform-origin`.

I believe, bending should work in a way so that the area an element has always stays the same. That means, to get a circle as shown the examples, you need a relatively long rectangle and not a square.

-----

Iterating on what @tabatkins and @dbaron said, bending is not an affine transformation and cannot be expressed using a matrix transformation. So I can see why they say that it doesn't fit to how `transform` is currently defined.

Though I can also see the point in saying that bending is some kind of (advanced) transformation. So it does somewhat fit to the `transform` property. It just isn't expressible as a matrix transformation.

-----

Regarding the use cases, I guess the main point related to the `<progress>` element is to keep its semantics and functionality while allowing to style it in a way that it is displayed circularly. The proposed solutions like using a conic gradient for that don't provide those semantics.

-----

The vertext shaders referenced by @tabatkins probably would be the most flexible but also the most complex solution to this. And the abandoned idea around custom filters indicates that this approach might not be viable, at least not in that form.

Sebastian

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 July 2023 21:42:11 UTC