Re: [css-shapes][css-images] Ellipse syntax(es) with a single radius

On Wed, Dec 9, 2015 at 11:37 AM, Alan Stearns <stearns@adobe.com> wrote:
> On 12/9/15, 10:47 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>On Sun, Dec 6, 2015 at 2:46 AM, Alan Stearns <stearns@adobe.com> wrote:
>>> On 12/6/15, 2:10 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>>Check radial-gradient() again - it requires 0 or 2 *length/percentage*
>>>>values, or 1 keyword.  You have ellipse() accepting 0 or 2 keywords
>>>>(along with 0 or 2 len/%).  You're not currently matching
>>>>radial-gradient() at all. ^_^
>>>
>>> I did note that discrepancy in the previous thread on this topic (that I linked with [2], and that you were part of). The main difference is that the shape functions have parameters that are always radius values, while the gradient syntax has a <size> argument that can either be radius value(s) or a more general sizing constraint (and the gradient syntax has additional keywords built to use in that general sizing constraint).
>>>
>>> So I’m trying to match the case where the gradient syntax specifies radius values. The fact remains that if I change the ellipse() function to allow only one radius value, it probably makes sense to change the gradient syntax to allow that as well. But all this accomplishes is the ability to create circles with one less parameter in the ellipse() function.
>>
>>I'm confused. Are you trying to match radial-gradient() or not?  In
>>the OP you said "I defined the ellipse function to match what we have
>>in radial-gradient()".  If this is what you wanted, then *match
>>radial-gradient()*.  The "radius" argument is either a single keyword
>>(which dictates the size of both radiuses), or two length/percentages.
>>I'm not sure I understand what you're arguing about here.
>
> I am trying to match radial-gradient() as much as makes sense. The radial-gradient function does *not* have a “radius” argument that can take a single keyword. It has a “size” argument that can (optionally) specify radius values. When it does specify radius values, you can supply 2 and only 2 of these values for an ellipse. That’s the part I’m matching.

radius, size, same thing. It's not a term of art.

> The change suggested in the bug would make this a valid ellipse():
>
> ellipse(3em)

That's the change that was offhand-suggested in the bug, yes.  It's
not "match radial-gradient()", tho.

> My point is that if we allow this, we should probably also allow
>
> radial-gradient(3em ellipse)
>
> And that’s currently invalid. That’s my entire point. Is it worth changing the radial-gradient() syntax to allow an author to explicitly set the x-radius value and omit the y-radius value in an ellipse?

No, I don't think that's valuable.  It was an offhand comment on the
bug, and not well thought-out.

What I'm suggesting here in this thread (and what my *intention* was
in the bug) is to match radial-gradient().  Right now it's confusing,
because it *almost* does, and there's a stated intention from you to
do so, but it doesn't quite get there. It's in an uncanny valley, and
that's usually a bad place; this is argued rather strongly by the
original bug, which was trying to do a valid radial-gradient() sizing
value, and was confused when it failed to work.

So: let's just make ellipse() match radial-gradient(), like you
apparently originally intended.  One keyword, or two
lengths/percentages (or nothing).

~TJ

Received on Wednesday, 9 December 2015 21:01:34 UTC