Re: Talk on radial gradients

On Thu, Sep 3, 2009 at 9:02 PM, David Perrell<> wrote:
> | That works elegantly for circles (and I like the ability to reuse the
> | gradient-line concept; I'm gonna rewrite some parts to use that), but
> | I'm not sold yet on ellipses.  How does one control the ellipse w/h
> | ratio?  It's implied when using 'sides' (whatever ratio is necessary
> | to touch the sides), but not for 'corners', as you sometimes have an
> | infinite number of ellipses that will intersect the four corners.
> As I defined it, the elliptical W/H ratio for 'auto' (or 'ellipse') is the same as the box W/H ratio anywhere along the diagonals between box corners - it's the ratio of distances from <center-point> to farthest sides.

Are you saying that the ellipse ratio is the side ratio even when you
specify 'corners'?  That works.

> | Also, specifying distances on an ellipse may be more difficult than
> | necessary here, if the gradient-line is pointing in a diagonal
> | direction.
> I meant gradient-line direction to be the same as <axis>, horizontal or vertical, not a diagonal. I probably helped you conclude otherwise by compounding an incorrect value derivation with "is the distance" instead of "is equal to the distance." I like 'gradient-line' better than 'axis' because (a) there are two axes, (b) 'axis' doesn't quite go with 'width' and 'height', and (c) it relates to linear-gradient.

Yeah, plus it makes it easier to explain just what "blue 70px" means.
Measure 70px from the start of the gradient line, and color the
circle/ellipse that intersects the gradient-line there blue.

> | Finally, we lose of the simplicity in both circles and
> | ellipses when the center is off-center, as we have to specify to align
> | to the closest or farthest side.
> Sorry, not sure what that means.

I don't blame you - if I didn't know what I was thinking, I wouldn't
have been able to parse it either.

Right now you're saying that you always base the ending-shape size on
the farthest sides/corners.  Is it useful to be able to base it on
closest sides instead?  Of course, as soon as you do that it opens up
the possibility of basing it on any adjacent pair of sides.  Probably
best to keep it simply referring to the farthest sides - that's the
most likely to be useful, and makes it less likely that you'll need to
use numbers over 100% in color-stops.

> | I like it, but 'contain' has a problem - the shape won't always be
> | contained within the box.
> Yes, 'contain' in this context would have to refer to containment only by the furthest sides.

Which makes me somewhat less willing to use it, though.

> | Actually... It doesn't match the ratio properly.  Spec error.  A
> | gradient centered on the left side should meet the other three sides,
> | so its actually twice as fat as it would be if the ratio was
> | maintained.  Do you think your proposal can address this properly?  I
> | think it's kind of important.
> With what I proposed, W:H ratio along corner-to-corner diagonals would be maintained. But as <center-point> moves outward from 'center' at other angles, the ratio would change. In a 100x100px box, <center-point> at 'center' (and outwards to any corner) would have a W:H ratio of 1:1, but at 'left' it would have a ratio of 2:1, 'contain'ed on 3 sides. I didn't consider this a problem because I don't see automatically-shaped-to-box-ratio radial gradients as very useful except when <center-point> is 'center' or at box corners.

Yup, I see what you mean, and agree with you.

> | ...I see the possibility that one can still
> | achieve ratios based sensibly on box information, without being stuck
> | with *only* the actual box ratio.
> So, how about replacing <shape> (and my previous definition of 'auto') with <aspect-ratio>? Value = width/height. Keyword 'circle' = 1, keyword 'box' = (box width)/(box height). Initial: box. Is this what you wanted - box shape maintainable for all positions? Could you not then specify modified box ratios, e.g. calc(box-.2)?

Nah, I like your ideas better now that I understand them, and the
ratio for "ellipse corners" has been established.

Expect to see an update to the draft to contain these changes later today.


Received on Friday, 4 September 2009 13:48:54 UTC