On May 10, 2013, at 11:11 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Fri, May 10, 2013 at 8:29 AM, Brad Kemper <brad.kemper@gmail.com> wrote: >> On May 9, 2013, at 3:05 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: >>>> Instead of having different functions for color effects like changing the >>>> brightness like Lea said earlier, the color() function could also do this: >>>> >>>> color(#ff4500, saturation - 20%); >>>> color(orangered, luminance 50%); >>>> >>>> Not sure if this approach is better than having different functions, though. >>> >>> Yes, this is my preferred solution now. >> >> I don't get it. If you have to include the color inside the that you are going to modify, that is a considerable shortcoming. > > The big win for the syntax I'm running with is that it lets you > manipulate colors stored in variables, generating a bunch more colors > off of it. Yeah, but I think it should be more usable without having to rely on variables. >> I'd much rather have it as this: >> >> color: #ff4500; color-adjust(saturation - 20%); >> background-color: orangered; color-adjust(luminance 50%, background-color, box-shadow, border-color); >> >> This way, I don't have to know the base color(s) in order to adjust a whole bunch of them. I could lighten all the elements of a certain class, make a whole bunch of things have translucent backgrounds, etc. without picking each color separately. > > I don't understand what syntax you're suggesting. You're putting a > function after the semicolon - is that supposed to be a property? Yeah, sorry. I made a boo boo. > Something else? > > I can see the potential for a property that adjusts the computed-value > of other color properties in this way. Call it 'color-adjust', have > its value be a number of property names and color-adjusters like what > color() has, in a comma-separated list. > > ~TJReceived on Friday, 10 May 2013 19:19:02 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC