Re: Talk on radial gradients

On Thu, Sep 3, 2009 at 3:47 PM, David Perrell<davidp@hpaa.com> wrote:
> 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.

Ah, sorry then.

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

Hm, okay.  (And yeah, I'm not that happy with my wording/naming in
that section either.)

So in your death-star example, it would be something like
radial-gradient(30px 30px circle sides, ...)?

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.
Also, specifying distances on an ellipse may be more difficult than
necessary here, if the gradient-line is pointing in a diagonal
direction.  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.



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

I like it, but 'contain' has a problem - the shape won't always be
contained within the box.  In your death-star example the circle is
'sides'/'contain' so that it meets the right side, but it clearly
extends past the top and left of the box.

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

Problem: under your current proposal the gradient-line doesn't need to
be horiz/vertical (it can be stretching from the center to a corner).
In that case, which axis is primary?  Is this axis a different length
than the gradient-line?

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

Given some appropriate resolutions to my questions, I like how this is going.

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

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.

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

Sorry, this was a result of me misinterpreting parts of your proposal.
 I see now that there's probably no magic behavior.

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

<shape> percentages are complexifying because people don't usually
think of ellipses in terms of ratios (at least, I don't), and they
also prevent you from using the box ratio.

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

Yeah, I like this example.

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

True, and in your proposal I see the possibility that one can still
achieve ratios based sensibly on box information, without being stuck
with *only* the actual box ratio.

~TJ

Received on Thursday, 3 September 2009 21:19:44 UTC