Re: Gradient syntax proposal

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?

>> 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?

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

> 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 doubt that measuring from the end will
be common enough to make the calc() inconvenient.

~TJ

Received on Wednesday, 19 August 2009 15:20:48 UTC