Re: Gradient syntax proposal

On Aug 19, 2009, at 6:59 AM, Tab Atkins Jr. wrote:

> I never responded properly to Brad's proposed
> second-slash syntax.
>
> I don't like it.  ^_^  I find it confusing to separate out a single
> color-stop from the rest and have it look exactly the same as the
> other color-stops, but be measured from a different place.

It wouldn't be just one stop. Stops after the first slash use the  
starting corner/side as their origin, and those after the second slash  
use the ending corner/side as their origin.

> If you can
> put multiple color-stops there, that gets even worse, because there is
> *no way* to establish an appropriate ordering between the two groups
> of color-stops other than whatever happens to fall out of the syntax.

I don't understand your argument.

> It also prevents the second-to-last stop from having a default
> location, unless the existing rule for resolving that can reach across
> the slash.  If so, sorta confusing.

I'm confused. Why would it prevent that?

> Just use calc() instead.  For that last red stop, write it as "red
> calc(100% - 52px)".  A bit complex, but the potential for confusion
> and ambiguity is dropped to 0.

How is it less confusing or ambiguous that way?

You just make it so that:

corner / start1, start2 / end1, end2

is equal to:

corner / start1, start2, calc(100%- end1), calc(100%- end2)

It is, in fact, syntactic sugar for that, but allows you to write it  
in a shorter, clearer manner, and encourages you (but does not force  
you) to group all you end-based lengths and percentages at the end. It  
wouldn't prevent you from using just the starting corner and calc() if  
you are real into that.

So, instead of writing this:

linear-gradient(top / 10px, 100px, 30%, 50%, 65%, calc(100% - 50px),  
calc(100% - 8px))

You could write this:

linear-gradient(top / 10px, 100px, 30%, 50% / 35%, 50px,  8px)

Received on Wednesday, 19 August 2009 14:31:49 UTC