@noamr, the template here seems to be incomplete. I was going to just delete the instructions, but I also notice that you missed a few fields. Would you mind updating it?

@noamr, the template here seems to be incomplete. I was going to just delete the instructions, but I also notice that you missed a few fields. Would you mind updating it?

Oops, sorry. Done I think?

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.

(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, which the function represents." It seems not-identical to me, given the level of re-specification.)

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, 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.

Thanks. FWIW, that would be very useful context to add to a specification.

Thanks. FWIW, that would be very useful context to add to a specification.

Noted, I'll add this to the specification. Thanks for the input!

Added spec PR: https://github.com/w3c/csswg-drafts/pull/11743

Hi @noamr, we discussed it at a TAG breakout and are happy with this feature being a good ergonomic improvement to CSS while compatible with the existing SVG syntax.