Re: Gradient syntax proposal

On Wed, Aug 19, 2009 at 12:22 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
>
> 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.

I sort of have a problem with *any* separator character if the two
lists are still supposed to be treated as one for the purposes of
ordering, implicit positioning, etc.  The idea that it acts *solely*
as a toggle switch and not a separator doesn't seem right to me.

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

And "linear-gradient(left / white 10px, silver, black end(10px))" isn't concise?

I dunno if it's worthwhile to actually *do* something like that, but
hey, I'm throwing it out there.

~TJ

Received on Wednesday, 19 August 2009 17:35:49 UTC