Re: Gradient syntax proposal

On Wed, Aug 19, 2009 at 10:35 AM, Brad Kemper<brad.kemper@gmail.com> wrote:
>
> On Aug 19, 2009, at 8:19 AM, Tab Atkins Jr. wrote:
>
>> On Wed, Aug 19, 2009 at 9:31 AM, Brad Kemper<brad.kemper@gmail.com> wrote:
>>>
>>> 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.
>>
>> K.
>>
>>>> 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.
>>
>> Consider:
>>
>> linear-gradient(left / white 20px, red 40px / blue 40px, black 20px)
>>
>> With a box that is 50px wide.  Do you just read them left to right
>> like normal and shift the values like in my current proposal?
>> (Effectively getting "white 20px, red 40px, blue 40px, black 40px".)
>> Or you let them intermingle so that you now have a gradient that goes
>> blue->white->black->red?
>
> If they have to be in order, then they have to be in order. This proposal
> does not change this. How is this a bigger issue with the second slash than
> it is with calc()?
>
>>>> 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?
>>
>> linear-gradient(left / white red / black 20px)
>>
>> The white can reasonably default to 0%.  But where does the red go?
>> 100%?  Halfway between the white and black?
>
> Yes, of course. The stops are all in order, so it is the same as if you
> wrote this:
>
> linear-gradient(left / white, red, black calc(100% - 20px))
>
> I don't understand your confusion.
>
>>>> 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?
>>
>> Well, it's certainly not ambiguous with calc().  I find it less
>> confusing, because then you have only a single list of stops which all
>> work the same way and order themselves as expected.
>
> 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.

>>> 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)
>>
>> 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?  If writing that is so annoying, then it'll be a
problem elsewhere in the language as well.  I expect that that is
going to be one of the major uses of calc() in general.
"from-end(50px)" would also work.  Wouldn't save on typing, but would
at least help prevent typos like "calc(10% - 50px)", and make your
intent crystal-clear.

>> I doubt that measuring from the end will
>> be common enough to make the calc() inconvenient.
>
> I do not doubt that at all. Of course for many gradients people will fairly
> commonly want some color stops to be a fixed distance from the end, and this
> way is much simpler and consistent than messing around with bg-position
> measurement pairs on a completely different measurement scale and 2D
> coordinate system.

~TJ

Received on Wednesday, 19 August 2009 16:19:37 UTC