W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-shapes] Optional radius arguments for ellipse shapes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Dec 2013 13:37:35 -0800
Message-ID: <CAAWBYDAx+0+ytbUMCk_oLo8kdho=QFYja25kQu1eQp_vMb3ePg@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: Bem Jones-Bey <bjonesbe@adobe.com>, "www-style@w3.org Style" <www-style@w3.org>, "rob.buis@samsung.com" <rob.buis@samsung.com>
On Mon, Dec 2, 2013 at 12:43 PM, Alan Stearns <stearns@adobe.com> wrote:
> On 12/2/13, 11:55 AM, "Bem Jones-Bey" <bjonesbe@adobe.com> wrote:
>>Hi Alan, et al.
>>Rob (cc'd) and I were talking about parsing of ellipse shapes[1], and we
>>noticed that the grammer seems to say that both <shape-radius> arguments
>>or none must be supplied, when the spec makes it sound like it would be
>>valid for just one <shape-radius> to be supplied, causing the second to
>>default to closest-side[2]. I believe that the grammar is what is
>>incorrect in this case, but can you clarify?
> I went back and forth on this issue, but for this draft decided to match
> the radial gradient syntax [1] which either allows you to omit both radii
> or requires you to supply both. The part of the spec that mentions the
> defaults only comes up if both radii are omitted. I was thinking that
> consistency was more important than defining a shortcut for what I assume
> will be a seldom-used case where an ellipse has a definite x-radius and a
> y-radius of closest-side.
> That said, I just noticed that radial gradients do not allow two keywords
> for ellipse radii, while shapes currently does. I expect this is to cover
> the *-corner keywords that would not make sense as a single ellipse
> radius. So we could consider diverging further if you think this case is
> important enough. I’m leaning towards keeping the draft as it is.

We need to converge the two definitions of radial shapes, is all.
Gradients were defined with only the things they needed, but we can
add to that.

Received on Monday, 2 December 2013 21:38:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC