Re: Talk on radial gradients

I'll assume that this was meant for the list, as it doesn't seem to be
private in any way.  ^_^

On Wed, Sep 2, 2009 at 8:17 PM, David Perrell<davidp@hpaa.com> wrote:
> Tab,
>
> | First, I don't provide an ability to set the center-point of the
> | ending-shape explicitly (right now it's the same as the
> | starting-point, but previously it was just the center of the box).  If
> | you specify a starting-point somewhere other than the center of the
> | ending-shape, your gradient skews...
>
> 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?  Right now the
ending-shape center is always at a symmetrical point (center of box,
center of side, or corner) so that it's easy to see how it uses the
box's width and height.

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

> | Second, I'm currently providing only a limited ability to control the
> | ending-shape.  If you have an ellipse, it automatically has the same
> | width/height ratio as the box (at first - you can always
> | squish/stretch it with background-size).  If you have a circle, it
> | aligns with either the sides or the corners in a reasonable way.
>
> I don't think allowing eccentricities other than just circle or the box rectangle is unreasonable. But, whatever, I'll still find the 'ellipse' keyword rather unintuitive. A circle is an ellipse, and 'ellipse' can result in a circle. I think 'auto' is more appropriate.

Yeah, circles are ellipses, but outside of math you rarely see them
referred to as such, just like squares are really rectangles (and
rhombusus!) but everyone still calls them 'squares'.  By using the
more general term you're making specific implications about what you
expect.  Plus, I have a secret reason for making the names explicit
(the secret is that I want to allow more than one type of radial
gradient).

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.

> | These limitations mean that you can specify what I feel are the most
> | important types of radial gradients very easily.  However, they do rob
> | you of a lot of precise control if you feel like you need it.
>
> Most important they may be, but I see inconsistency between your linear- and radial-gradients in terms of the amount of control. You argued for more control on one, and now for less on the other.

Ah, but the context is important.  linear-gradient() has very little
*need* for controls - it's a simple concept and it's very easy to
allow it to take into account the relevant box information.  I felt
that Brad was trying to make it *too* simple.

On the other hand, radial-gradient() is way more complicated, with
lots of information that can potentially be fed to it in several
different ways.  This is the sort of thing that's probably actually
*easier* to deal with in script, where you can just say "here's the
box's xywh, do your calculations and let me know when you're ready".
Trying to express this in a declarative manner is hard.  >_<

> | "top left" is a valid <bg-position>.  ^_^
>
> Oops, didn't realize that. I've always put x-direction first, consistent with offsets.

Yeah, I usually do too just to keep myself consistent.  But "top left"
just sounds so much better.

~TJ

Received on Thursday, 3 September 2009 14:11:53 UTC