- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 19 Aug 2009 10:22:38 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: David Perrell <davidp@hpaa.com>, www-style@w3.org
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.
Received on Wednesday, 19 August 2009 17:23:22 UTC