CSS shape() function

[noamr]

こんにちは TAG-さん!

I'm requesting a TAG review of CSS shape() function.

{{One paragraph summary of the feature, ideally copy-pasted from your Explainer.}}

• Explainer¹: https://drafts.csswg.org/css-shapes-2/#shape-function
• Specification: https://drafts.csswg.org/css-shapes-2/#shape-function
• WPT Tests: https://wpt.fyi/results/css/css-masking/clip-path?label=master&label=experimental&aligned&q=shape%28 https://wpt.fyi/results/css/css-shapes?label=master&label=experimental&aligned&q=shape%28
• User research:
• Security and Privacy self-review²: https://gist.github.com/noamr/6897ab8bddbcc6189cd39761f60d48f2
• GitHub repo: w3c/csswg-drafts
• Primary contacts:
  • @noamr, Google Inc, developing and editing the spec
• Organization/project driving the specification: Google, Apple
• Multi-stakeholder support³:
  • Chromium comments: Chromium is actively implementing this.
  • WebKit comments: WebKit is actively implementing this. https://bugs.webkit.org/show_bug.cgi?id=238371
  • Mozilla comments: CSS shape() function mozilla/standards-positions#1153
  • {{...include feedback/review from developers, implementers, civil society, and others}}
• Status/issue trackers for implementations⁴: https://g-issues.chromium.org/issues/40829059 https://bugs.webkit.org/show_bug.cgi?id=238371

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: This is already enabled by default in chromium and webkit.
• The group where the work on this specification is currently being done: CSS
• The group where standardization of this work is intended to be done (if different from the current group):
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google

You should also know that...
There is an open issue to bring more CSS-like capabilities to path, in a way that stays closer to SVG.

[martinthomson]

@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]

@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?

[martinthomson]

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

[noamr]

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.

[martinthomson]

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

[noamr]

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!

[noamr]

Added spec PR: w3c/csswg-drafts#11743