This overall seems promising, but a few inline comments. The only blocking one is the question about open spec edits.
On Thursday, January 23, 2025 at 4:42:34 AM UTC+9 Chromestatus wrote: Contact emails nrosent...@chromium.org Explainer None I was able to piece together an explainer by looking through the spec and its examples. In the future, pointing to them a bit more directly, or pulling them out into a paragraph or two, would be helpful. Specification https://drafts.csswg.org/css-shapes-2/#shape-function Summary shape() allows responsive custom shapes in CSS properties that accept a shape, currently limited to clip-path. It lets the author define a series of commands, equivalent to the commands in path(), but where the commands accept responsive units (e.g. % or vw), as well as any CSS values such as custom properties or rather than pixel-values. See https://drafts.csswg.org/css-shapes-2/#shape-function Blink component Blink>CSS <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> TAG review None TAG review status Pending Risks Interoperability and Compatibility None *Gecko*: No signal (https://github.com/mozilla/standards-positions/issues/ 1153) *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=238371) Safari has already implemented this, available in STP. *Web developers*: Positive See citations: https://jamesmcgrath.net/ scaling-svg-clippath/ https://css-tricks.com/unfortunately-clip-path-path- is-still-a-no-go/ https://stackoverflow.com/questions/29495919/how-to- apply-clippath-to-a-div-with-the-clippath-position-being-relative-to-the https://stackoverflow.com/questions/31210466/convert- svg-path-data-to-0-1-range-to-use-as-clippath-with-objectboundingbox https://stackoverflow.com/questions/53618192/create- responsive-svg-clip-path-making-svg-path-responsive *Other signals*: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability None Do we currently have any special DevTools support for clip-path()? If so, we might want to consumer the same thing for shape(). Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes https://wpt.fyi/results/css/css-shapes/shape-functions?label=master&label= experimental&aligned&q=shape (anything beginning with shape-) https://wpt.fyi/results/css/css-masking/clip-path?label= master&label=experimental&aligned&q=shape and https://wpt.fyi/results/css/ css-masking/clip-path/animations?label=master&label= experimental&aligned&q=shape (clip-path-shape-*) Flag name on about://flags CSSShapeFunction I don't think this is an about://flags flag. (At least, I don't see one in my Chrome Dev.) Probably it's best to remove this from ChromeStatus. Finch feature name CSSShapeFunction Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/40829059 Estimated milestones Shipping on desktop 135 DevTrial on desktop 134 Shipping on Android 135 DevTrial on Android 134 Shipping on WebView 135 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None https://github.com/w3c/csswg-drafts/labels/css-shapes-2 has quite a lot of open issues. Several of them relate to shape(), I believe: - https://github.com/w3c/csswg-drafts/issues/11358 - https://github.com/w3c/csswg-drafts/issues/10697 - https://github.com/w3c/csswg-drafts/issues/10644 - https://github.com/w3c/csswg-drafts/issues/10647 - https://github.com/w3c/csswg-drafts/issues/10667 Could you comment on these (and any others I might have missed) to let us know if any of them reflect either (a) potential backward-incompatible changes (#10647 seems especially scary in that regard), or (b) mismatches between the currently live spec and our implementation? If they are just potential future backward-compatible enhancements then that's fine, but I can't tell at a glance whether that's the case for all of them. Link to entry on the Chrome Platform Status https://chromestatus.com/ feature/5172258539307008?gate=5143998661132288 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink- dev/6759c7eb.2b0a0220.2dfede.0004.GAE%40google.com This intent message was generated by Chrome Platform Status <https://chromestatus.com>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/427fecaf-3551-4c98-92c3-7e5f566e4629n%40chromium.org.
