W3C home > Mailing lists > Public > www-style@w3.org > August 2009

Talk on radial gradients

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 23 Aug 2009 13:18:56 -0500
Message-ID: <dd0fbad0908231118p45add5b8qcb711df24f54ec04@mail.gmail.com>
To: www-style list <www-style@w3.org>
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.

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.

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.

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 Sunday, 23 August 2009 18:19:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT