Re: Gradient syntax proposal

On Aug 19, 2009, at 9:18 AM, Tab Atkins Jr. wrote:

>> They are still ordered as expected. Any list of things can be  
>> divided into
>> those that are at the beginning and those that are at the end. It  
>> doesn't
>> change the order, and I am not changing that. I am only changing  
>> the point
>> of reference for those at the end, because that is often the most  
>> meaningful
>> measurement for the last stops.
>
> Ah, k.  I was expecting the / to actually be separating them into two
> independent lists of color-stops.  You're apparently using it solely
> as a parsing toggle.  That was unclear to me, and I think violates
> expectations of how the / works.  Using that glyph produces, in my
> mind, a strong concept of separation.

Well, it is dividing it into two subgroups: those that are measured  
against the start and those that are measured against the end. But the  
whole list would still be in order. I suppose a pipe character or  
something would be OK too, but I don't really have a problem with it  
being a slash.

>>>> [...] 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)
>>>
>>> Nod, I'm just not sure that the sugar is worth the added complexity.
>>> The calc() leans on an existing construct that will become more
>>> understood as time goes on.
>>
>> I don't see how writing a slash is more complex that repeatedly  
>> writing a
>> math equation that almost always starts with "100% - ".
>
> Isn't the obvious answer, then, to make a new function that obviates
> the "100% - " bit?

No. I would like to keep the grammar for gradient concise, because  
with multiple stops it quickly gets long anyway.