Re: [CSSWG] Minutes and Resolutions 2009-08-12

On Aug 13, 2009, at 1:08 AM, Robert O'Callahan wrote:

> That seems far more complicated than what we currently have.

Not to me, not for the most common uses, which are gradients that  
stretch from one edge to another, one corner to another, and/or are  
either vertical or horizontal. For those, an angle is simpler than a  
coordinate point.

> By writing it as a 'gradient' rule you don't benefit background- 
> clip, background-position, background-repeat, multiple backgrounds,  
> and falling back to a background image. It's not extensible to other  
> kinds of gradients, and doesn't handle repeating gradients.

That's kind of the point, since the conversation is about making  
gradients into an image type. You want to use a bunch of background  
properties for the image definition, and then use them again when that  
image is used in a background? That would be pretty confusing, and  
most of the time not that useful. As an author, I will probably never,  
ever need a gradient to repeat over and over again in a background as  
tiles. Using background-position to define the position of the  
starting and stopping points (but not the in between points) just  
complicates it unnecessarily, when an angle and 0 or more percentages  
will do the trick.

Once the gradient is considered an image, then it can be used with  
multiple backgrounds, fallback to another image type, background-clip,  
and even repeating tiled gradients.

> And even so,
>
> { gradient: white #666 -90deg; }
> [..]
> seem much less clear than
> background: linear-gradient(top, white, bottom, #666);

Perhaps that is because you are already very familiar with your more  
verbose form. If you were familiar with the default being linear  
(which is not hard to remember, since linear gradients are far more  
common), then leaving the word "linear" out of it would not be any  
less clear. Then just listing 2 colors and the angle between then is  
pretty damn simple.

In fact, having an angle and a distance from the zero point of that  
angle is actually much less ambiguous than something like "20%  
center" (as in one of the examples on the mozilla page). Is the 20%  
horizontal or vertical? I know I should know that, but I always have  
to stop and think about it when using backgrounds because it is the  
opposite order than when using two values for borders, padding,  
margin, etc. And angles are what I am most used to when creating  
gradients in PhotoShop and other applications. I really don't find  
anything clear about "20% center, 30% center". So to figure out what  
angle is meant by that I have to imagine where those points lie and  
then draw an imaginary line between them. If clarity is the goal, then  
just tell me the angle, or let me type an angle. I don't want to do  
math to convert between angles and two points on a coordinate system.

Once you go to multiple color stops, my way groups each color and the  
percentage stop much more simply, without resorting to lengthy,  
multiple functional notations to do that. My way uses the same  
notation for the first and last stops as for the stops in-between,  
instead of listing both the position and the color using a completely  
different notation for the first and last stops. I'd have to say that  
for linear gradients, my way is simpler AND clearer, without giving up  
anything in power.

For radials, the most complicated part is the keywords, but they are  
also pretty simple and clear, basically just the combination of [width  
| height | longest | shortest] with [sides | corners]. They allow the  
creation of oval gradients, gradients based on the size of the box (in  
several different ways), and do not force you to switch from using  
percentages in linear to fixed-distances-only in radial. I specified  
percentages for both, but it could easily accommodate fixed distances  
for both too. This makes my way more powerful, but it is also easier  
to learn and understand too, because the notation is mostly identical  
to the linear version. I find the examples on the mozilla page much  
more confusing, as they switch between two lengths and a comma, to a  
single length and a comma, back to two lengths again, then back to a  
single length again. Seriously? You think that's clearer to someone  
not already mired in it?? I guess it allows you to have radial center  
that is not actually centered with the outside of the radial, but that  
hardly seems like a useful reason to make it so complex.

I think a far better way to approach this is to make the commonest  
uses dead simple (three values for the simplest gradients, go to  
corners or sides with radial gradients), and add extra values in a  
simple, consistent, easy-to-understand-as-possible manner for the more  
complex cases. But having different center points for the inside of  
the gradient than the outside is an extreme edge case and not worth  
the excessively hard to fathom syntax it requires.

Received on Thursday, 13 August 2009 16:00:58 UTC