Re: radial-gradient() proposal

On Nov 3, 2009, at 7:41 PM, Ryan Seddon wrote:

> On Tue, Nov 3, 2009 at 10:21 PM, Robert O'Callahan <robert@ocallahan.org 
> > wrote:
> On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr.  
> <jackalmage@gmail..com> wrote:
> I'm finally happy with my radial-gradient() syntax.  You can view it
> at http://www.xanthir.com/:4bhipd (scroll down past the
> linear-gradient() examples).
>
> We landed an implementation of this spec on Firefox trunk today ---  
> with a -moz prefix, of course --- so it'll be in the latest nightly  
> build by now. We think it's pretty complete. So people who want to  
> experiment with this in a browser can now do so. Feedback appreciated.
>
> Why was linear-gradient, radial-gradient decided? To me it would  
> make more sense to have the syntax as gradient-linear, gradient- 
> radial, gradient-repeating-radial etc. They're all gradients and  
> would make more sense, especially if scanning a CSS document you  
> could determine a lot quicker that those styles are all gradients.

In discussion with Tab and Elika, we may remove repeating gradients  
(unless a pressing use-case comes up). If we don't, then I agree that  
repeating-linear-gradient() scans more poorly than gradient-linear- 
repeating(). If we end up with just linear-gradient() and radial- 
gradient(), then I don't much care, and matching SVG is a bonus.

As promised in the meeting on Tuesday, here are my other comments on  
Tab's Gradient proposal (<http://dev.w3.org/csswg/css3-images/#gradients- 
 >):

In general, the proposal has a lot of shorthand "smarts" that make it  
convenient for the author to hit common use cases (e.g. gradients that  
cover the entire box); there seem to be a lot of special behaviors  
baked into the property. It's not clear to me what the canonical forms  
are. Describing what's returned from getComputedStyle() would help.

linear-gradient:
	The proposal allows authors to omit the position, and/or the angle.
	Intuitively, I would assume that if <bg-position> were omitted then  
some default point is used (top left, or 50% 50%). However, that's  
isn't true: instead, we fall into some smarts about using a certain  
corner based on the angle. If angle is omitted, I would assume that  
it's 0. However, that isn't true either; the angle is determined by  
reflecting the <bg-position> about the center of the box. I understand  
the author convenience, and trying to hit the common use cases, but I  
think straying from the common notion that omitted values get some  
predicable default should be done with caution.
	I think my real unease here stems from my desire to see a linear  
gradient specified precisely by the end points, and having a simple  
way to deduce the end point from the angle. So I propose the following.

	A linear gradient is specified by two points, and optionally an  
angle. In the absence of the angle, those two points are the endpoints  
of the gradient. If the angle is present, then the start point of the  
gradient is the first point and the axis of the gradient is given by  
the angle. The endpoint of the gradient is obtained by finding the  
point on a line perpendicular to the axis which intersects with the  
second specified point.
	If no point is specified, the start point is assumed to be the top  
left (and thus the second point is bottom right).
	If only one point is specified, then the second point is obtained by  
reflecting the first point about the center of the box.
	If the second specified point lies on a line from the first point  
with the specified angle, then the gradient renders as a solid color  
using the color of the last(?) stop.

This gives the following behavior:

	linear-gradient(yellow, blue) -- start point defaults to top left,  
reflect about center to get an end in the bottom left: get diagonal  
gradient.
	linear-gradient(left, yellow, blue) -- horizontal gradient from left  
to right
	linear-gradient(top, yellow, blue) -- vertical gradient from top to  
bottom
	linear-gradient(top left, bottom right, yellow, blue) -- end points  
are specified, get diagonal gradient.
	linear-gradient(10% 20px, yellow, blue) -- diagonal gradient from 10%  
20px to 90% (height - 20px)
	linear-gradient(45deg, yellow, blue) -- start point is top left, end  
point is bottom right, get 45deg gradient.

This still has the nice "fill the box" properties, and allows a lot of  
common gradient types without having to use the angle argument. There  
still isn't a single canonical form -- the angle is "absolute", 0deg  
being up (I think; the current proposal doesn't say), so saying that  
the angle defaults to 0 does not work. Specifying the angle as  
relative to the line between the end points doesn't help either,  
because then you can no longer maintain a 45deg gradient as the end  
points move around.

This form also still has ambiguous parsing of:
	linear-gradient(0, yellow blue)
and similar, where the 0 can be parsed as a position or angle, unless  
we require angle units.

I haven't thought about radial-gradient yet, but I do see that the  
current radial gradient proposal does not allow the author to place a  
radial gradient in an arbitrary spot that does not necessarily touch  
the edges or corners of the box. I think this use case is important,  
for example content that wants to put a gradient on the <body> that  
creates a glow around some element on the page.

Simon