Thanks Helmut.
I didn't realize there was actual interop risk here when I approved.
Reading
https://github.com/mozilla/standards-positions/issues/1450#issuecomment-5666667133
a bit more carefully, it seems like Mozilla only half shipped this. Is
my read correct?
If ellipse() is going to change soon-ish, maybe it's better to hold off,
given that WebKit is the only engine that has shipped it. If so, do you
think there's value in only shipping circle() now, to match Mozilla?
On 9/17/26 1:23 a.m., Helmut Januschka wrote:
gosh, sorry, shortly after LGTM3, CSSWG discussed the open ellipse()
grammar question, but did not reach a resolution:
https://github.com/w3c/csswg-drafts/issues/10812#issuecomment-5701278743
The question is specifically whether ellipse() should continue
accepting two independent *-corner radii, as WebKit currently ships
and the WPTs expect, or use a singular *-corner value that determines
both radii. circle() is unaffected.
My read is that the likely path is additive, retain the shipped
two-value behavior and define the singular form.
However, a singular-only resolution could require changing the
accepted syntax or resulting geometry.
Given the existing WebKit behavior, are you comfortable with me
proceeding with the M156 flag flip and following up after CSSWG
resolves this, or should I wait?
the flag-flip CL:
https://chromium-review.googlesource.com/c/chromium/src/+/8419499
cheers
helmut
Am Mi., 16. Sept. 2026 um 17:13 Uhr schrieb Rick Byers
<[email protected]>:
LGTM3
On Tue, Sep 15, 2026 at 3:11 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
LGTM2
On Tue, Sep 15, 2026 at 3:18 AM Mike Taylor
<[email protected]> wrote:
On 9/14/26 5:57 p.m., Helmut Januschka wrote:
Hi Alex,
The main pattern this serves is the “circular reveal”,
animating |clip-path: circle()| so the circle fully
covers its box. The required end radius is the distance
from the center to the farthest corner, which authors
today approximate with:
* a hardcoded |circle(141.42%)| (only correct for
square boxes), or
* computing |Math.hypot(width, height)| in JS and
injecting it via a custom property.
The JS workaround is common enough that Chrome View
Transitions documentation
<https://developer.chrome.com/docs/web-platform/view-transitions/same-document>
teaches it for the circle-reveal demo (see the
|Math.hypot| snippet under “Animating with JavaScript”).
That doc even notes: “The animation ends with the circle
having a radius to the farthest corner. Although,
hopefully this will be possible with CSS in future.”
With it, the pattern becomes |circle(farthest-corner at x
y)| no JS, no aspect-ratio assumptions, correct for any box.
This is also partly an interop fix. The keywords are
already part of the css-shapes-1 grammar
<https://drafts.csswg.org/css-shapes-1/#basic-shape-functions>
(|circle()| takes |<radial-size>|, defined in css-images,
which includes |closest-corner| and |farthest-corner|),
and they already work in |radial-gradient()|, so authors
reasonably expect them in |circle()|/|ellipse()|. WebKit
shipped support in 2024 and exported the WPTs for it:
WebKit/WebKit#31678
<https://github.com/WebKit/WebKit/pull/31678>
Positions:
* WebKit: support (implemented and shipped) -
WebKit/standards-positions#719
<https://github.com/WebKit/standards-positions/issues/719>
* Mozilla: shipped behind flag -
mozilla/standards-positions#1450
<https://github.com/mozilla/standards-positions/issues/1450>
Thanks - LGTM1
Updated the feature entry as well.
do you have any hints on how i can gather more
developer-signal, or is there any documentation on how to
get this?
Since this is a "catch up" feature, signals aren't a
blocking concern (for me personally, anyways). In general
though, you could find blog posts of developers asking for
a feature (or describing their excitement about it...),
issues filed by developers, or comments in existing issues
giving support, etc. Sometimes these can surface in CSSWG
discussions, or even TAG issues.
cheers,
helmut
Am Mo., 14. Sept. 2026 um 23:11 Uhr schrieb Alex Russell
<[email protected]>:
I'm a little less worried about browser signals here
than I am about developer signals. Do we have
confirmation that this solves an important problem
for web authors?
Best,
Alex
On Wednesday, September 2, 2026 at 11:36:29 AM UTC-7
Mike Taylor wrote:
Yes, thanks. :)
https://github.com/WebKit/standards-positions
https://github.com/mozilla/standards-positions
On 9/2/26 2:22 p.m., Chris Harrelson wrote:
Hi Helmut,
Just to clarify: Mike is asking for Mozilla and
Safari standards positions issues, not
additional developer signals.
On Wed, Sep 2, 2026 at 11:20 AM Helmut Januschka
<[email protected]> wrote:
trying to figure out to get signals
Am Mi., 2. Sept. 2026 um 20:19 Uhr schrieb
Helmut Januschka <[email protected]>:
sadly, same as on my other feature
entry, i forgot the checkmark, fixed! sorry
[email protected] schrieb am Montag,
24. August 2026 um 19:23:24 UTC+2:
On 8/23/26 10:06 a.m., Helmut
Januschka wrote:
*Contact emails*
[email protected]
*Specification*
https://drafts.csswg.org/css-shapes-1/#basic-shape-functions
*Summary*
The circle() and ellipse() CSS
basic-shape functions accept the
closest-corner and farthest-corner
radius keywords, in addition to the
existing closest-side and
farthest-side. These keywords
resolve to the Euclidean distance
from the shape center to the
nearest or farthest corner of the
reference box, matching the
long-standing behavior of
radial-gradient(). They work in
clip-path, shape-outside, and
offset-path, so the same shape
syntax accepted by gradients now
works for shapes. CL:
https://chromium-review.googlesource.com/c/chromium/src/+/7767079
*Blink component*
Blink>CSS
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
*Web Feature ID*
shapes
<https://webstatus.dev/features/shapes>
*Motivation*
The <radial-extent> keywords
closest-corner and farthest-corner
are defined for radial gradients
and have been interoperably
supported there for years. The
circle() and ellipse() basic-shape
syntax in CSS Shapes Module Level 1
shares the <shape-radius>
production with gradients, but
Blink (and Gecko) only accepted
closest-side / farthest-side for
the basic shapes. That means
authors who want a circle that
exactly inscribes the reference
box's farthest corner have to
hand-compute sqrt(w*w + h*h)/2 or
fall back to a radial-gradient()
mask, even though the keyword
exists in the same value space.
This change fills in the missing
keywords so basic shapes have the
full <radial-extent> set:
closest-corner: the distance from
the center to the closest corner of
the reference box. farthest-corner:
the distance from the center to the
farthest corner of the reference
box. For ellipse(), which accepts
two independent <shape-radius>
values in current implementations,
each axis resolves independently to
the corner Euclidean distance. A
spec ambiguity exists about whether
ellipse() should accept one
<radial-extent> covering both axes
(per the spec text) or two
independent ones (current
implementation reality). This was
discussed in
https://github.com/w3c/csswg-drafts/issues/13814 and
the conclusion from the thread was
that the existing two-value
interpretation is fine to keep.
*Initial public proposal*
/No information provided/
*TAG review*
/No information provided/
*TAG review status*
Not applicable
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
/No information provided/
/Gecko/: No signal
/WebKit/: No signal
Can we request signals?
/Web developers/: No signals
/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?
/No information provided/
*Debuggability*
/No information provided/
*Will this feature be supported on
all six Blink platforms (Windows,
Mac, Linux, ChromeOS, Android, and
Android WebView)?*
No
Why not?
*Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
*Flag name on about://flags*
/No information provided/
*Finch feature name*
BasicShapeCornerRadius
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://crbug.com/361617757
*Estimated milestones*
Shipping on desktop 155
Shipping on Android 155
Shipping on WebView 155
Shipping on iOS 155
*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).
/No information provided/
*Link to entry on the Chrome
Platform Status*
https://chromestatus.com/feature/5100672946143232?gate=5910108950364160
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKSp4M_xW9Y4_1x56p_kLHBsY8_NdBUgYAqLjcKTUUsS2w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKSp4M_xW9Y4_1x56p_kLHBsY8_NdBUgYAqLjcKTUUsS2w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQp%3DoqVbRRX_iUxx3hn7_24XDW_vG5Sb1kJEvrQhUEWCg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKQp%3DoqVbRRX_iUxx3hn7_24XDW_vG5Sb1kJEvrQhUEWCg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-XQD4u7_3N5i9z7MupFRq_jJVQ5WK5ABwJyr6t6o9_bg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-XQD4u7_3N5i9z7MupFRq_jJVQ5WK5ABwJyr6t6o9_bg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f68dc11f-78a5-4b7f-a0f3-cc397934aa2c%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f68dc11f-78a5-4b7f-a0f3-cc397934aa2c%40chromium.org?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B2u4AdJRMbLmnTe9m5Ja%2B9vkSLYQy0KZLL2VQ059Tsbg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B2u4AdJRMbLmnTe9m5Ja%2B9vkSLYQy0KZLL2VQ059Tsbg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1507a76c-bc92-4c8a-831f-17827dfb7f60%40chromium.org.
