Re: [CSS3] Some thoughts about functions, notation and gradient().

On Aug 20, 2009, at 10:25 AM, "L. David Baron" <dbaron@dbaron.org>  
wrote:
> I don't like the use of '/' as a delimiter; it feels to me that if
> you're writing something like:
>  a / b, c, d
> the natural grouping of that syntax is:
>  (a / b), c, d
> whereas in this draft it means:
>  a / (b, c, d)
> I'd prefer replacing the '/' with ',' over the current syntax,
> though I'd also be open to better alternatives.

When I first made a suggestion about gradient syntax, I had a comma  
there instead of a slash, but someone (fantasai, IIRC) suggested the  
slash in order to separate the list of color-stops from the other  
values needed (such as angle). The color-stops are a list of two or  
more, so they have commas between each one, just as there are commas  
between a list of font-families or a list of backgrounds. So that part  
makes sense to me. Each item on the list has a color and can have an  
explicit position along the gradient path (either percentage of the  
path or a length from the beginning of the path), so we are using  
spaces to separate the color from the position in each stop. I suppose  
the spaces could be slashes and the commas could be spaces, but that  
doesn't seem quite right either. Or maybe keep the commas, replace the  
space in each color-stop with a slash, and just use a space to  
separate the other values?

> I don't know why you chose the default starting point for <angle>
> without <bg-position> to be one of the box's corners.  This leads to
> asymmetric results for both 'inside' and 'outside'.  Why not say
> that the gradient line is symmetric around the center of the
> background positioning area, at the given angle.  For inside, the
> length of the gradient line would be the length that touches the
> edges of the background positioning area.

Personally, I don't think 'inside' is needed. I don't see gradients  
like that much in the wild, and Tab's use case for 'inside' was to  
keep the gradient confined to one corner.

> For outside, the length
> of the gradient line would be the longest length such that the
> perpendiculars to the ends of the gradient line intersect the
> corners of the background positioning area.  (Longest because there
> are shorter such lengths, but they intersect the wrong corners.)

I think that amounts to the same gradient (you are even using similar  
wording as I did for describing where it ends). The path you describe  
is parallel to the one starting from a corner and has the sane length.  
Each color in the gradient is perpendicular to both paths.

> Given that, I'm not sure what the use case is for <bg-position>
> <angle>.

There is not a strong use case for that.

>  I think it makes more sense to use an angle with zero
> points or two than it does with one.  (Using an angle with two
> points would follow the same rules as using it for zero, except
> using the rectangle formed by those two points instead of the
> background positioning area.)

background positioning area doesn't figure into it, since we are  
talking about a funtional notation to substitute for URL() anywhere  
that images can be used. Zero points makes the most sense.

Besides using angle, it was pointed out fairly early on the need to  
have a gradient go from corner to corner, no matter the dimensions of  
the 'image' box. Thus <bg-image.> was introduced to indicate starting  
and ending points, but my feeling for that is that we only need to  
indicate a starting corner (or side) for that, and then stretch the  
gradient across to the opposite corner (or side).

> But I suspect I may have missed something in all those messages I
> haven't read; feel free to point me to the relevant use cases (or,
> even better, add an example to the document showing why the current
> approach is better).
>
>
> I also fear that the syntax may be too compact and thus unreadable,
> but I'm also not sure that there are any alternatives that I prefer.
>
>
> The proposal also needs to address radial gradients at some point.
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/

Received on Thursday, 20 August 2009 19:45:40 UTC