- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Fri, 14 Aug 2009 16:24:46 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Sent from my iPhone On Aug 14, 2009, at 3:16 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Fri, Aug 14, 2009 at 4:57 PM, Brad Kemper<brad.kemper@gmail.com> > wrote: >> On Aug 14, 2009, at 1:47 PM, fantasai >> <fantasai.lists@inkedblade.net> wrote: >>> Brad Kemper wrote: >>>> >>>> On Aug 13, 2009, at 4:35 PM, Tab Atkins Jr. wrote: >>>>> >>>>> Just linear gradients for now: >>>>> >>>>> >>>>> http://www.xanthir.com/document/document.php? >>>>> id= >>>>> d65df9d10442ef96c2dfe5e1d7bbebf7aa42f2bcf24e68fc3777c4b484fa8a4ce55fed2189cac20ccad8686127f4c08917c4ca8b7614e9f89c2a950ec083a9c6 >> >> >>>>> >>>>> ~TJ >>>>> >>>> I won't get into my objections to [inner | outer] right now, but >>>> about >>>> the rest of this: >>> >>> We could make the default 'outer', which should address your >>> concerns, no? >> >> If others really think this is necessary and are willing to add >> this extra >> complexity, yes. > > I've changed the default to 'outside'. > > If implementors don't like it, I can always remove the keyword. I > just think it would be useful to me. > >>> I'd use the keywords 'inside' and 'outside', btw. I think they fit >>> better, >>> and also they're already in the parsing system (for list-style- >>> position). >>> >>>> One of the things I really hate about using "<bg-position>, >>>> <bg-position>" is that comma to separate the two lengths or >>>> keywords on the >>>> left from those on the right. Since commas are already being used >>>> to >>>> separate color-stops, this just makes the whole thing harder to >>>> read, >>>> because they are no longer used consistently to group like >>>> things. When they >>>> are used only for color-stops, then you can see in a glance how >>>> many >>>> color-stops there are instead of having to study it more closely >>>> with a line >>>> full of distances and commas. For instance, I find the following >>>> very hard >>>> to read, and it probably doesn't even make sense (which is >>>> another problem >>>> with this kind of construction). |linear-gradient(10px 30%, 100% >>>> 4%, 50% >>>> green, 20% blue)| >>> >>> I completely agree. How about using a keyword? >>> >>> linear-gradient(10px 30% to 100% 4%, green, blue 20%, navy); >> >> Do you really think people will really need to start on such a >> precise xy >> point instead of just some distance or percentage from the corner? >> I don't, >> but maybe calc() can be used to figure that distance from the corner. >> >> If I wanted to start say, 30% from the top, and end at the bottom, >> I would >> write that as "linear-gradient(top, green 30%, blue 20%, navy)". Or >> if I >> wanted to be a few degrees off from straight down, I would do >> "linear-gradient(-87deg, green 30%, blue 20%, navy)". I think these >> are both >> much cleaner, and provide all that an author will really need. > > All right, changed my mind. That looks confusing as *hell*. It looks > like you meant to write "blue 20%, green 30%, navy" but swapped them > for some reason. What? Why? Wasn't green her first color? Wasn't it supposed to start 30% from the top? > I don't like it at all. Mine was simpler. > >>> linear-gradient(left to right green, 50% blue, 100% navy); >> >> That's very close to what I suggested, except for the "to right" part > > Yeah, but allowing the literate form (in addition to the short "left" > form) makes a *wonderful* parallel to the full <bg-position> > construction, so it's easy to learn and understand. This suggestion > from Elika was a definite win in my mind. > > Though, it'd be written with a "/" between the direction and the > color-stops in my current proposal. > > ~TJ
Received on Friday, 14 August 2009 23:25:38 UTC