W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: radial-gradient() proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 6 Sep 2009 16:57:02 -0500
Message-ID: <dd0fbad0909061457s3a0548c0j329cea7e4511d34d@mail.gmail.com>
To: David Perrell <davidp@hpaa.com>
Cc: www-style list <www-style@w3.org>
On Sun, Sep 6, 2009 at 4:34 PM, David Perrell<davidp@hpaa.com> wrote:
> Tab Atkins Jr. wrote:
> | Using the full <angle> gives
> | us a direct analogue to linear gradient so there's less relearning,
> | even if a lot of the power gets wasted.
>
> Any analogue is oblique and creates confusion. I went through your spec multiple times, trying figure what relationship <angle> had to an ellipse if not the angle of the major axis. Unless you have ellipse axes other than vertical and horizontal, you have no need to specify a gradient-line at an arbitrary angle.

It has nothing do with the axes of the ellipse; it specifies the angle
of the gradient-line, which is used solely for placing color-stops.
It is absolutely vital to know the direction of the gradient-line when
position a color-stop with a <length>, because there's quite a bit of
difference in where "yellow 50px" gets drawn on a 200px by 100px
ellipse based on whether you're measuring down the major axis, the
minor axis, or somewhere else entirely.

> | You do bring up a good point that I want to address, though, and that
> | it's not possible with an explicit angle to reliably measure lengths
> | to a corner.
>
> No, but you can compute the angle to a corner from a start-point, a width, and a height. If your gradient-line corresponds to your size line, then it's very clear how distances relate to the shape.

If you know the width and height of the box, sure, though I'd prefer
not to do any trig at all when creating my CSS files.  However, this
syntax has been designed to be maximally useful in the face of boxes
with *unknown* dimensions, where such an angle can only be estimated.

> When you have an <angle> that requires a lengthy explanation as to why
> only two of countless options are really useful, it seems to me it's time
> to reconsider its value.

I'm not sure I understand how an explanation is lengthy.  However, I
do accept that <angle> may be best addressed in some other manner.

> | I've revised that sentence.  Does it make more sense now?
>
> Insofar as which way the gradient-line extends, yes. As regards the reasons for providing such an option, no.

K, good enough.

> | Elliptical gradients don't derive a single reasonable point from
> | <size> in the case of closest-side or farthest-side, they have two.
>
> Closest-side, farthest-side, etc., are measured on a vertical or horizontal line from the start-point to a side. Isn't that the line on which you'll most likely want to align things? Consider also that to-a-side and to-a-corner measurements represent the longest lines on which all distances from 0-100% appear within the box.

Not for ellipses; they measure a horizontal *and* vertical line to the
two nearest sides.  There's no reasonable way to automatically
distinguish between the two.

Similarly, for an ellipse the to-a-corner distance is, I think, rarely
going to be a better choice than the major or minor axis.  Again, you
can't reliably tell which is better automatically; this depends on
your layout needs.

For circles, of course, these questions are all moot.  They align to a
single side, and have only a single radius no matter what direction
you're looking in.

> If specifying specific angles is necessary, then it seems that a variable with keywords instead of angles - where 'size-line' might be the default option - would be better than <angle>.

Specifying angles *is* necessary, even if only to distinguish between
0deg and 90deg.  If I were to do this, I would use keywords like [
horizontal | vertical | major | minor ] to specify which axis of the
ellipse to measure along.  I'm not completely certain this is actually
simpler, though.

~TJ
Received on Sunday, 6 September 2009 21:57:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT