Re: Talk on radial gradients

From: "Tab Atkins Jr." <jackalmage@gmail.com>
> Now that I'm pretty much completely happy with my linear-gradient
> proposal, I wanna talk about radial gradients.  They bring several
> complications with them that don't exist in linear gradients, and
> there are several different ways we can take the proposal that are
> mutually exclusive (at least if we want to maintain a halfway
> reasonable syntax).
> 
> So, let's start with the existing webkit radial gradient.  Let me be
> frank - I think they suck.  No offense to the Webkit team.  ^_^  I
> think their goal was "make minimal changes to the linear-gradient
> syntax", and so what they ended up with was a tool for creating pretty
> circles, *not* a tool for solving common author uses for radial
> gradients.  The whole reason we're trying to add linear-gradient() to
> CSS is because there is information we need to display gradients in an
> attractive manner that isn't available to us when we're in photoshop
> or gimp, like the width or height of the box we're putting the
> gradient on.
> 
> The webkit syntax doesn't take advantage of any of this information.
> You specify a start circle and end circle in absolute pixel units, and
> then specify color stops at % between those two circles.  I can do
> this in gimp all day, and letting CSS do it for me really isn't much
> of a win.
> 
> However, it's pretty obvious that the webkit syntax is an early draft.
> If this was actually specced you'd be able to specify a general
> <length>.  Using em isn't *that* different from using px, though.
> Better would be the ability to use <percentage>, as that is
> information that we sometimes can't even *estimate*, and it's often
> far more important to align things to a box dimension than to a
> text-based length.  This is simple enough for the two points, but it
> brings up very difficult questions when you try to apply it to the
> radius, *which is the most important part*.
> 
> The radius is the most important bit because in my personal
> experience, radial gradients are used over *an entire box* to provide
> a smooth color transition.  I haven't actually been able to ever *use*
> a radial gradient in any site I've coded, precisely because I don't
> have the ability to match the intent in the design documents that it
> should stretch with the box.  What this boils down to is that thinking
> of radial gradient as "makes circles" is wrong - in practice, it's
> "makes a radially symmetric fade based on the box".
> 
> So, lets get to my actual thoughts.
> 
> First, I don't currently think a starting radius is ever necessary.
> You can accomplish the same by putting a <length> on the first
> color-stop.  I'm not completely convinced of this, though - the same
> argument could apply to linear-gradient, and there using a <length> on
> the first/last color stop potentially clashes with % used on interior
> stops, as the % is based on the *whole* length of the line rather than
> the space between the terminal stops.  So I may revise my opinion
> here.

I don't think a starting radius is useful. We could use a color stop.

> Second, I don't think an ending circle is necessary *at all*, with a
> point or radius.  As I mentioned above, in every case of a radial
> gradient that got passed to me in a design document, it was based
> directly on the box itself.  Thus the box itself should provide the
> ending circle.  There are several ways to do this, and I think they're
> all valid - frex, you could want to end with a circle as wide as the
> box, or as tall as the box, or as large as the smaller or larger
> dimension, or large enough to fully contain the box (the circle
> circumscribes the box).  All of these seem to be valid and reasonable,
> and I would expect that they'd see real use in decent numbers.

I think it can be. A radial gradient is specified by two things : 
* a center
* an ending circle
===> a point of the ending circle
===> the radius of the ending circle

> Third, and this is something I'm not completely sure on yet but think
> is probably important, you should be able to specify elliptical
> shapes.  This is mostly important for my stated case of having a
> gradient conform to the box.  I think it will be common to want a
> gradient to always match a box's shape pretty much exactly, even as it
> changes in both width and height.  This would produce an oval if the
> box isn't square, though, and I think that's desirable.  For example,
> consider a header that is 200px tall but as wide as your screen (let's
> say 1000px) that you want to slap a radial gradient on.  If I'm
> limited to circular gradients, I'll either have a 200px diameter
> circle in the center of the header and solid color everywhere else,
> which looks dumb, or a 1000px diameter circle that looks similar to a
> linear-gradient.  What I really want is something 1000px by 200px that
> transition from a start color in the center to an end color at the
> edges.

We could then change the syntax to add possibly a center and two radius

It would be like:
    
    radial-gradient(top left, 100%, 100%, ...)

This would be a perfect ellipse centered top left.

> This produces an odd clash with the color-stop position, though.  A
> color-stop specified in % is no problem, as it would just specify an
> oval with its two axes a % of the width and height.  But a color-stop
> specified as a <length> is ambiguous.  Does it necessarily restrict
> you to a circle?  Or does it refer to one dimension, and the other
> axis is automatically adjusted to match the shape of the box when
> appropriate?  I've got a possible solution to this problem.
> 
> 
> I'm tying all my thoughts together into a first draft of the syntax,
> which I'll send in a separate message shortly.
> 
> ~TJ
>

Received on Monday, 24 August 2009 09:55:40 UTC