I'm not willing to compromise on usability and intuitiveness for the sake of powerful-but-obscure features. Sure, it may be easy for you or me or someone else reading this thread in detail to understand the difference between lighten($color) and lighten($color, true). But what about people reading your stylesheet later? What about users who want scaling behavior but don't know it?
I think we can do better than lighten($color, true). I think we can come up with a way of expressing this that makes it at least somewhat clear what's going on for someone who hasn't read the documentation. And I'm certainly not willing to add a sub-par API in the meantime. On Mon, Aug 30, 2010 at 12:51 AM, Eric Meyer <[email protected]> wrote: > Nathan, > > I agree but have a hard time seeing the issue when it comes to changes > that don't affect default behavior. Half of CSS3 doesn't make sense > unless you read the spec in detail. If you don't get it, don't use it. > > It also seems like a funny argument when it is clear that people don't > grok the way it is now. > > Keeping default behavior the same, and adding an optional argument for > those who do read the manual seems like a great step to me. > > > > On Aug 30, 1:29 am, Nathan Weizenbaum <[email protected]> wrote: > > The problem is I don't think any of these names adequately convey to a > > casual user who may not have read the documentation what the difference > is > > between the two functions. > > > > On Mon, Aug 30, 2010 at 12:06 AM, Chris Yates <[email protected] > >wrote: > > > > > > > > > The PHamlP functions did behave differently - that was my > > > misunderstanding; having come across this thread they now behave as > > > Sass. > > > > > I chose "absolute" to describe the way things happen as the amount of > > > change is absolute irrespective of the colour value (i.e. if > > > lightness($colour) == 60%, lighten($colour, 30%) gives > > > $lightness($colour) == 30%, and if lightness($colour) == 70%, > > > lighten($colour, 30%) gives $lightness($colour) == 40%), and > > > "relative" where the amount of change depends on the original colour > > > value, (i.e. if lightness($colour) == 60%, lighten($colour, 30%, > > > 'true;) gives $lightness($colour) == 40%). But I'm certainly not going > > > to get hung up about the name; "proportional", "dependant" are another > > > couple of suggestions - must be loads more. > > > > > On Aug 29, 11:12 pm, Nathan Weizenbaum <[email protected]> wrote: > > > > Are you saying that the phamlp Sass functions behave differently than > the > > > > standard ones? If so, that's a bug in the phamlp implementation and > > > should > > > > be fixed. > > > > > > I don't believe that the word "relative" will adequately communicate > to > > > > users what the difference between the two functions is. The current > > > behavior > > > > is relative: lighten($color, 30%) makes $color 30% lighter, relative > to > > > its > > > > current lightness. Thus, neither adding a parameter named $relative > nor > > > > adding versions of the function named "relative" will make it clear > to > > > the > > > > user what's going on. > > > > > > Triggering different behavior based on units and magnitude of the > > > parameter > > > > is even more opaque to the user, especially given that decimal values > and > > > > percentages are conceptually very similar. > > > > > > On Sun, Aug 29, 2010 at 1:26 PM, Chris Yates < > [email protected] > > > >wrote: > > > > > > > Dam - just released PHamlP V3 and guess what? Yep - did the colour > > > > > functions as relative. > > > > > > > Two suggestions to cope with absolute and relative adjustment: > > > > > 1. add a SassBoolean as a 3rd optional parameter to darken(), > > > > > lighten(), saturate(), and desaturate(). If set true the adjustment > is > > > > > a relative adjustment, if not given or set false it is an absolute > > > > > adjustment. That should mean existing code behaves as currently. > > > > > 2. add darken_rel(), lighten_rel(), etc. > > > > > > > For opacify() and transparentize() I think the answer is just look > at > > > > > the adjustment value. If it's unitless and between 0 and 1 it's > > > > > absolute, a percentage means it's relative. > > > > > > > On Aug 26, 9:57 am, Nathan Weizenbaum <[email protected]> wrote: > > > > > > *Blade*: The summary: Sass/CSS use the word "saturation" in a > > > different > > > > > way > > > > > > than Photoshop, as Eric said. When you change the lightness in > Sass, > > > it > > > > > > doesn't change the CSS saturation, but it does change the > Photoshop > > > > > > saturation, because they're actually different definitions of > > > > > "saturation". > > > > > > > > You shouldn't have to use mix(). darken() actually does darken > the > > > color; > > > > > if > > > > > > that's what you're looking for, use darken(). Certainly don't use > > > mix() > > > > > to > > > > > > get closer to the photoshop results, because it won't (or if it > does > > > > > it'll > > > > > > be by accident). > > > > > > > > If someone's bored and wants to make a hsb plugin for Sass, tat > would > > > be > > > > > > pretty neat. > > > > > > > > *Eric*: If you can come up with a better name for the scaling > > > versions of > > > > > > the functions, I'd be happy to have them in core. The problem is > > > finding > > > > > a > > > > > > name that clearly conveys that it does the same thing but > > > differently. > > > > > > > > On Wed, Aug 25, 2010 at 5:30 PM, BladeBronson < > > > [email protected] > > > > > >wrote: > > > > > > > > > In my examples, I can see that SASS reports the same saturation > > > value > > > > > > > for a color before and after it is darkened, but Photoshop > reports > > > a > > > > > > > difference. I barely understand why (grin), but it doesn't > matter > > > to > > > > > > > me. The SASS team has given this more thought than I have and > I'm > > > sure > > > > > > > it makes sense for darken() to work the way that it does. I'm > able > > > to > > > > > > > achieve the colors that I'm expecting by using mix() with a > degree > > > of > > > > > > > black instead of darken(), so I'm all set! > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Haml" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]<haml%[email protected]> > <haml%[email protected]<haml%[email protected]> > >< > > > haml%[email protected]<haml%[email protected]> > <haml%[email protected]<haml%[email protected]> > > > > > >. > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/haml?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Haml" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<haml%[email protected]>< > haml%[email protected]<haml%[email protected]> > >. > > > For more options, visit this group at > > >http://groups.google.com/group/haml?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
