W3C home > Mailing lists > Public > www-style@w3.org > August 2009

Re: Gradient syntax proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 19 Aug 2009 08:35:25 -0700
Cc: David Perrell <davidp@hpaa.com>, www-style@w3.org
Message-Id: <DD3D0288-6927-408B-BA55-FF7BDEBBEED6@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

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.

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

> 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.
Received on Wednesday, 19 August 2009 15:36:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:28 UTC