Re: [w3ctag/design-reviews] CSS `shape()` function (Issue #1033)

noamr left a comment (w3ctag/design-reviews#1033)

> Thanks! (That link is particularly interesting to me, because I don't like what appears to be a drift between this and SVG.)
> 
> On that topic, is there more that you have about why the CSS working group chose to invent an entirely new syntax for what is substantially similar to SVG `<path>`? It seems to me like you are deliberately losing a bunch of advantages (like being able to prototype shapes using SVG and just copy them over) and inviting the possibility of the two drifting apart. Without an explainer, there's nowhere that really covers alternatives.

Those advantages are not "lost" because `path()` still exists, and a conversion function from `path()` to `shape()` is trivial.
`shape()` is a superset of what SVG/`path()` can do because it's responsive and SVG is only scalable and not responsive.
In that sense, converting the other way, from `shape()` to `path()` or SVG, requires knowing the CSS state, as well as the size of the box. The same `shape()` can result in many different paths - a shape is a "recipe" to make paths based on the CSS environment.

> 
> (I'm not 100% sure that this is indeed not an SVG path because the spec says "The rest of the arguments define a list of path data commands, identical to that of an [SVG Path](https://www.w3.org/TR/SVG11/paths.html#PathData), which the function represents." It seems not-identical to me, given the level of re-specification.)

Yea, it was more identical at the beginning, I'll remove this from the spec.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1033#issuecomment-2668022765
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1033/2668022765@github.com>