RE: Talk on radial gradients

Tab Atkins Jr. wrote:
| I'll assume that this was meant for the list...

No, it was a reply to your message that didn't CC the list. But that's OK.

| > I didn't suggest different start and end center-points - only 
| that offsets apply in addition to keywords, allowing the ellipse 
| to be positioned anywhere. This seems more in tune with your 
| linear-gradient proposal. Your radial-gradient proposal seems 
| more in tune with Brad Kemper's keyword-only positioning for 
| linear gradient.
| | Oh, I didn't understand you to be saying that.  Hmm.  How does one
| then refer to the box information in a sensical way?

Quite simply:
<color-stop>s are measured along <axis> from the <center-point>. This line corresponds to <gradient-line> for linear-gradient. The 100% point on the <gradient-line> (er, I mean <axis>) is the distance from <center-point> to the farthest corner (<size>='corners') or to the farthest side (<size>='sides') in the direction of the axis.  

(It seems reasonable that 'background-size' keywords 'cover' and 'contain' could be used in place of 'corners' and 'sides'.)

When <shape> is 'circle', color-stop distances are the same in all directions. When <shape> is 'auto' ('ellipse'), color-stop distances along the secondary axis will be the primary-axis <color-stop> distances * (the distance from the <center-point> to the farthest side along the secondary axis / the distance from <center-point> to the farthest side along the primary axis). And when shape is <percentage>, color-stop distances along the secondary axis will be a percentage of those along the primary axis.

This all strikes me as no more difficult to understand than your references to box information for outside edge points.

Default gradients with <center-point> on corners (and on corner-to-corner diagonals) will be the same shape as with your current spec. Gradients with <center-point> on sides will not be. I don't see that as a significant loss. How often do you require a radial gradient centered on a side that matches the box's W/H ratio?

| I'm not particularly interested in having magic behavior only for
| certain areas.  That's confusing and nonintuitive.

Behavior determined by well-defined rules isn't hocus-pocus. Keyword incantations...hmm.

| The reason I don't currently allow explicit eccentricity/ratio control
| is simply because I don't think it's useful enough to justify
| complexifying the syntax past what it already is.  Radial gradients
| have *way* more variables than linear gradients if you want to be
| useful.  I'm currently unhappy with the complexity of it, and am
| looking for ways to reduce that.

Neither <center-point> positions nor <shape> percentages are particularly complexifying, inasmuch as there are no new variables and keywords are still available. 

| > | These limitations mean that you can specify what I feel are the most
| > | important types...
| >
| > Most important they may be...

...but they may not. As for <center-point> positioning, I can see plenty of uses for positioning the center point to highlight a particular child element while having the outward gradation cover much of the box. (E.g.: http://hpaa.com/csstest/planetary.htm.) I see this as far more desirable than a radial gradient centered on a corner or in the middle of an edge.

In some cases, effective highlighting would require that the gradient's eccentricity be neither circular nor matching the box.

Yes, in most cases those effects could be produced by background-sizing and background-positioning a centered circular gradient. But not easily.

David Perrell

Received on Thursday, 3 September 2009 20:48:22 UTC