Discussion:
[css-shapes][css-images] Ellipse syntax(es) with a single radius
(too old to reply)
Alan Stearns
2015-12-05 18:18:18 UTC
Permalink
Raw Message
Hey all,

In a bug [1], it’s noted that the ellipse() function is defined to only accept 0 or 2 radius values. If one radius is provided, it’s an invalid shape function. Tab suggested in the bug that we allow a 1-radius ellipse, and just set the second radius to the same as the first.



As I recall [2], I defined the ellipse function to match what we have in radial-gradient(), where if an ellipse ending-shape is explicitly used, you can only use 0 or 2 radius values.

I don’t much care whether we allow one-radius ellipse syntax or not, but if we do I think we should also change radial-gradient() to match. I don’t think it’s terribly useful to have a one-radius ellipse that devolves to a circle, though. So I’m slightly inclined against the change because I don’t think the limited use warrants mucking around with gradients.

Thanks,

Alan

[1] https://code.google.com/p/chromium/issues/detail?id=555684
[2] https://lists.w3.org/A
Tab Atkins Jr.
2015-12-06 01:10:18 UTC
Permalink
Raw Message
Post by Alan Stearns
In a bug [1], it’s noted that the ellipse() function is defined to only accept 0 or 2 radius values. If one radius is provided, it’s an invalid shape function. Tab suggested in the bug that we allow a 1-radius ellipse, and just set the second radius to the same as the first.
As I recall [2], I defined the ellipse function to match what we have in radial-gradient(), where if an ellipse ending-shape is explicitly used, you can only use 0 or 2 radius values.
I don’t much care whether we allow one-radius ellipse syntax or not, but if we do I think we should also change radial-gradient() to match. I don’t think it’s terribly useful to have a one-radius ellipse that devolves to a circle, though. So I’m slightly inclined against the change because I don’t think the limited use warrants mucking around with gradients.
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. ^_^

~TJ
Alan Stearns
2015-12-06 10:46:10 UTC
Permalink
Raw Message
Post by Tab Atkins Jr.
Post by Alan Stearns
In a bug [1], it’s noted that the ellipse() function is defined to only accept 0 or 2 radius values. If one radius is provided, it’s an invalid shape function. Tab suggested in the bug that we allow a 1-radius ellipse, and just set the second radius to the same as the first.
As I recall [2], I defined the ellipse function to match what we have in radial-gradient(), where if an ellipse ending-shape is explicitly used, you can only use 0 or 2 radius values.
I don’t much care whether we allow one-radius ellipse syntax or not, but if we do I think we should also change radial-gradient() to match. I don’t think it’s terribly useful to have a one-radius ellipse that devolves to a circle, though. So I’m slightly inclined against the change because I don’t think the limited use warrants mucking around with gradients.
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.

[2] https://lists.w3.org/Archives/Public/www-style/2013Dec/0015
Tab Atkins Jr.
2015-12-09 18:47:51 UTC
Permalink
Raw Message
Post by Alan Stearns
Post by Tab Atkins Jr.
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.

~TJ
Alan Stearns
2015-12-09 19:37:02 UTC
Permalink
Raw Message
Post by Tab Atkins Jr.
Post by Alan Stearns
Post by Tab Atkins Jr.
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.

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

ellipse(3em)


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?
Tab Atkins Jr.
2015-12-09 21:00:44 UTC
Permalink
Raw Message
Post by Alan Stearns
Post by Tab Atkins Jr.
Post by Alan Stearns
Post by Tab Atkins Jr.
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.
Post by Alan Stearns
ellipse(3em)
That's the change that was offhand-suggested in the bug, yes. It's
not "match radial-gradient()", tho.
Post by Alan Stearns
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
Tab Atkins Jr.
2017-04-20 06:16:45 UTC
Permalink
Raw Message
Post by Tab Atkins Jr.
So: let's just make ellipse() match radial-gradient(), like you
apparently originally intended. One keyword, or two
lengths/percentages (or nothing).
Following up on this for Images 3 DoC reasons:

We're marking this as Rejected/OutOfScope for Images; we don't need to
do anything in particular for elliptical radial gradients, and the
problem that I *intended* to point out in the bug that inspired you to
send this issue is that ellipse() should change to match
radial-gradient(), not the other way around. (Timing, and usage
numbers, make it clear that if either need to change it's definitely
ellipse().)

~TJ

Loading...