Csswg-drafts: [css-shapes] ellipse with single <shape-radius>

[ewilligers]

The ellipse shape used by clip-path, shape-outside, offset-path is defined to accept \

However, Safari also accepts a single \

[ewilligers]

I just noticed

\ ... If omitted it defaults to closest-side.

This may be the justification for accepting one radius value, but I suspect

ellipse( <shape-radius>{1,2}? [ at <position> ]? ) would be clearer.

[fantasai]

@ewilligers If we're using the “If omitted it defaults to closest-side” clause to justify the singe <shape-radius> case, then it would mean a single <shape-radius> expands to that in one axis and closest-side in the other. Then it's unspecified which side, but also it's inconsistent with how CSS works, where an omitted second value is doubled.

So clearly something needs to be fixed in the spec here! What's the implemented behavior so far? :)

[ewilligers]

Both Blink and Webkit treat ellipse(20% at 30% 40%) as ellipse(20% closest-side at 30% 40%). Further, they serialize each as ellipse(20% at 30% 40%).

Edge and Firefox don't support basic shapes.

[upsuper]

Edge and Firefox don't support basic shapes.

Firefox supports basic shapes in clip-path, and shape-outside is currently behind pref layout.css.shape-outside.enabled because there are still something not fully implemented.

[svgeesus]

I suspect ellipse( <shape-radius>{1,2}? [ at <position> ]? ) would be clearer.
I agree, that makes it clear that either one or two radii can be specified.

However, it is still odd that ellipse(20% closest-side ...) has a handy shortcut while ellipse(closest-side 20% ...) does not.

[AmeliaBR]

As a CSS author, I would expect that ellipse(50px at center) would expand to ellipse(50px 50px at center).

If the Blink/WebKit behavior is adopted instead, I definitely don't think that the serialization should drop closest-side when specified as the second radius value.

[svgeesus]

As a CSS author, I would expect that ellipse(50px at center) would expand to ellipse(50px 50px at center).

To be honest that is what I would expect, also.

[smfr]

https://bugs.webkit.org/show_bug.cgi?id=181745

[css-meeting-bot]

The Working Group just discussed [css-shapes] ellipse with single <shape-radius>, and agreed to the following resolutions:

• RESOLVED: Leave the spec as is, will not extend the spec to support the item raised in #2175

The full IRC log of that discussion

<dael> Topic: [css-shapes] ellipse with single <shape-radius>

<dael> github: https://github.com/w3c/csswg-drafts/issues/2175

<Chris> q+

<dael> ericwilligers: I want to know, should we adopt what blink and wk have shipped or is this a bug? I've only just noticed so I started a use counter but we won't have data for months

<dael> Chris: What they have is a bit weird. It's more of an error correction as far as I can see.

<dael> astearns: This is just an error case so I don't mind what we choose to do. Going with what's impl seems easiest.

<dael> ericwilligers: We could easily do what AmeliaBR suggested.

<dael> fantasai: Does web content use this format?

<dael> ericwilligers: No idea.

<dael> Chris: Use counter was just installed.

<smfr> shapes are very little used in the wild

<dael> fantasai: As AmeliaBR points out it's very unusual for us to not double in both axes. If there isn't web content dependency it makes more sense to do that. There's only one place we don't do that, background-size, and I consider that a mistake.

<dael> Rossen_: ericwilligers when do you expect data? If this is still very early on and it's a bug level fix to back out by preference is someone who is going to be impl down the road would be to go siplier and not have that behavior.

<dael> ericwilligers: 12 weeks until data.

<dael> Rossen_: Okay. Wow.

<dael> ericwilligers: Maybe you can collect data server-side. I've never done that.

<dael> gregwhitworth: Can we resolve one way or another and if the data comes back and proves us wrong we can revert? I don't see a ton of use of Shapes in general.

<AmeliaBR> Current spec is that single radius value is invalid, so it would be fine to add support for two values later.

<dael> Rossen_: We can. We'll have to resolve today for the spec text. In ther presense of more evidence and patterns on the web we can rediscuss. For now I wanted to hear from blinke ngineers if you'd push back in terms of resolution.

<AmeliaBR> The problem is Blink/WebKit supporting two values, but with a non-intuitive behavior.

<dael> smfr: I would be fine to treat this as a bug fix in webkit.

<dael> Rossen_: Blink?

<dael> ericwilligers: I don't see any benefits of the current approach. I wouldn't be able to change without data.

<AmeliaBR> s/two values/one value/

<dael> Rossen_: We're talking about changes to spec. Impl changes would happen when youg ethte data. I'm asking if you object to resolve on the contrary to your current behavior. In the presense of more data we'll review again.

<dael> ericwilligers: No objection.

<dael> Rossen_: Sounds like 2 impl shipping are not objecting to keeping the spec as-is. Any other opinions/objections?

<AmeliaBR> s/youg ethte/you get the/

<dael> RESOLVED: Leave the spec as is, will not extend the spec to support the item raised in #2175

[fantasai]

Note: elliptical radial gradients also require two arguments: https://www.w3.org/TR/css3-images/#radial-gradients

[AmeliaBR]

More than a year later, I note that Chrome hasn't changed their implementations (I just got dinged on the lack of interop when trying to test other things). What were the results of your use counter, @ericwilligers ? Is it safe to remove, or do we need to revisit the resolution?

[ewilligers]

Blink use counts for ellipse:
BasicShapeEllipseNoRadius 0.00005%
BasicShapeEllipseOneRadius 0.00002%
BasicShapeEllipseTwoRadius 0.1%

It is safe to remove: Blink issue