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

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".


>  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.


> 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.

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.

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.

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Received on Thursday, 13 August 2009 20:39:48 UTC