Re: [css3-images] Proposed Gradients changes

On Sun, Nov 28, 2010 at 8:58 PM, Rik Cabanier <> wrote:
> Hi,
> Thanks for the offer!
> It seems that in the current specification radial gradients are more powerful than axial ones and both syntaxes look very different.
> Is this because you're trying to match an existing implementation?

No, it's just because both are designed to address the use-cases I
found important, which are different between the two.  Linear
gradients are fundamentally simpler than radial ones, so I can get
away with a simpler syntax for them.  Their syntaxes actually look
very similar in the simple cases; it's just the corner cases that I
felt were important enough to address that make them different.

On Sun, Nov 28, 2010 at 8:38 PM, Rik Cabanier <> wrote:
> 'extend' signals if an endpoint 'extends' from the gradient. Typically you want this turned on in a gradient.
> If it's turned off, the gradient might not fill its bounding box. PDF and PostScript define this keyword, but our applications almost always leave the extend on.

CSS Gradients always extend outwards to infinity.  The color of the
last color-stop determines the color of the gradient past it (and the
color of the first color-stop determines the color of the gradient
before it).

If you want a gradient to stop at a particular point, just overlap a
transparent color-stop with it.  For example, this gradient will go
from white to black over half of the box, and then immediately stop:

background: linear-gradient(white, black 50%, transparent 50%);

> SVG, Flash and XPS also have the 'repeat' and 'reflect' keywords that let you tile a gradient like you describe. The last 2 keywords imply a specific size for the gradient so you can't use top/bottom or left/right in the css.
> It seems that you can define a keyword with 'none', 'extend' (or 'pad'), 'repeat' and 'reflect'.

The ability to repeat a gradient was determined to be not quite useful
enough to address in this specification.  Is there significant usage
of this ability in Flash, SVG, or other technologies you're familiar

Reflection can be easily achieved manually by just repeating the
existing color-stops in reverse order.

> 'focal point' is used with radial gradients for when you don't want the beginning and ending circle to have the same midpoint. (see attached SVG file) There are different ways to get this effect but it doesn't seem that CSS lets you do this.

The original Webkit syntax for radial gradients allowed this, as you
explicitly specified both a starting ellipse and an ending ellipse,
which could have different centers.  I decided that this wasn't
sufficiently useful to justify the additional complexity it would add
to the syntax.  CSS Gradients are explicitly designed to be simple;
more complex cases like conic gradients should be handled by SVG.

> What is the image box? Is that the bounds of the tag that has the CSS gradient?

Yeah, whatever the gradient is being drawn into.  The spec goes into
more explicit detail about what it means and how to determine the size
of the box.

On Sun, Nov 28, 2010 at 11:38 PM, Rik Cabanier <> wrote:
> Yes, for tiling rotated gradients, there's a need to have a 'background-rotate' keyword which doesn't seem to exist.

I don't understand this.  What are you trying to achieve?

> I agree that CSS gradients should be as simple as possible.
> The spec for axial gradients looks reasonable.
> I think you could add another positioning parameter so you can define a custom begin and endpoint. (this is close to a webkit-gradient)
> Ie linear-gradient(center top center bottom, yellow, blue) would render the default axial gradient
> But maybe this is already too advanced...

Yeah, I actually *just* dropped that from the syntax.  In practice, it
appears that gradients are always done from one edge of a box to
another, so linear gradients are specified with just an angle, or a
side/corner to go between.  If necessary, a power user can achieve
more precision by placing the first and last color-stop at points
other than 0% and 100%, but this appears to be hardly ever necessary.

> The radial gradient spec seems more complicated than it needs to be.
> Extending my proposal for axial to radial:
> radial-gradient(startx starty endx endy, radius1 radius2 ratio, endpoint-color,...)
> with
> startx, starty = position of the centerpoint of first endpoint (default: center center like background-position)
> endx, endy = position of the centerpoint of the last endpoint (default: center center)
> radius1 = radius of the inner circle (default: 0% like background-size)
> radius2 = radius of the outer circle (default: 50%)
> ratio = the ratio of the height/width of the circle. (default: auto = ratio of the bounding box)
> wouldn't this cover most of what you're trying to accomplish? My proposal also includes moving the focal point.

Unfortunately, no.  One of the things I found important in my design
was to easily accommodate both 'cover' (the 100% ellipse circumscribes
the box, so the 100% color touches the corners) and 'contain' (the
100% ellipse is circumscribed by the box, so the 100% color touches
the edges).

When you work out the math, you find that the two ellipses are related
by a factor of about 1.41.  (To be specific, sqrt(2).  Also, the
'cover' ellipse is constrained to have the same axis ratio as the
'contain' ellipse, because there are infinitely many circumscribing
ellipses.)  Both cases are common enough that I don't particularly
want people to have to do relatively complicated algebra to figure
that out, though.  I don't want to paper over the problem by having a
"switch" that changes the meaning of percentages in the radius
argument, either.

As well, the specification of the radiuses can instead be moved into
the color-stops pretty easily, similar to how you can have a linear
gradient start/stop at arbitrary points by putting the first/last
color-stop at a particular point.  Rather than having, say, an inner
radius of 50px and an outer radius of 100%, you can just put the first
color-stop at 50px and the last at 100%.

So, I don't think radius arguments are good at all; I believe my
current solution solves the use-cases better.  Currently, I consider
the utility of a radial gradient with different centers for its start
and end shapes to be minimal and thus I haven't included the ability,
but I could extend it to allow that fairly easily with sufficient
convincing otherwise.


Received on Monday, 29 November 2010 22:11:05 UTC