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

Sent from my iPhone

On Aug 13, 2009, at 1:39 PM, "Robert O'Callahan"  
<robert@ocallahan.org> wrote:

> On Fri, Aug 14, 2009 at 4:00 AM, Brad Kemper <brad.kemper@gmail.com>  
> wrote:
> 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.
>
> It's fewer tokens, but writing "left, right" seems simpler than  
> "-90deg".

Not to me. I'm quite used to thinking of linear gradients in terms of  
angle. (btw the equivelent to -90deg would be "top, bottom", but  
270deg is fine too, if it helps. Left to right would be 0deg.)

> 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.
>
> I agree, and that's not what we're doing. I think you've  
> misunderstood what how our stuff works, which is fair enough since  
> we haven't really described it properly. I will do that in a jiffy.

I meant even what you had in the example, in which a band of gradient  
repeated many times at an angle.


>  Using background-position to define the position of the starting  
> and stopping points (but not the in between points)
> ust complicates it unnecessarily, when an angle and 0 or more  
> percentages will do the trick.
>
> background-position isn't all that useful, you're right, but the  
> other properties are.

But my point is that this is being discussed in term of using gradient  
as an image type, so it would be weird and redundant to have a bunch  
of background properties inside it, and then use it instead of URL()  
inside of an element's own background properties.

> 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.
>
> You have to know how to interpret the angle. This is not obvious  
> since we don't use angles like this elsewhere.

It seems pretty clear conceptually. If the angle takes it up and to  
the right (0-90 degrees) then it would start in the lower left corner.

> 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?
>
> True in that example, but if one of the coordinates is 'top',  
> 'left', 'right' or 'bottom' it's very obvious.

But not for other points. Whereas "20%    at a 45 degree angle (from  
the only corner that makes sense with that)" is much more clear to me,  
and avoids nonsensical values like having the first coordinate as  
"right" and the last coordinate as "bottom".

> 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.
>
> That is in fact quite useful for making objects appear to be lit  
> from one direction. I've seen examples of this already. If we don't  
> want it we can just get rid of the additional center argument.

It is far less common, which is why in my propsal it is an optional  
<point> that can be tacked on to the very end.