- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 19 Aug 2009 08:35:25 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: David Perrell <davidp@hpaa.com>, www-style@w3.org
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