- From: Bem Jones-Bey <bjonesbe@adobe.com>
- Date: Tue, 3 Dec 2013 10:01:46 -0800
- To: Alan Stearns <stearns@adobe.com>
- CC: "www-style@w3.org Style" <www-style@w3.org>, "rob.buis@samsung.com" <rob.buis@samsung.com>
On Dec 2, 2013, at 12:43 , 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. I don't have a strong opinion either way, this is definitely a corner case. So I'm happy to leave the draft as it is. Thanks, - Bem
Received on Tuesday, 3 December 2013 18:02:13 UTC