RE: radial-gradient() proposal

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.
| 
| 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. 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'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.

| 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.

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>. 

David Perrell

Received on Sunday, 6 September 2009 21:35:08 UTC