Re: Color tweaking functions

I have had the opposite encounter with theme-ability. Choosing a base color not in the same triad (primary vs. tertiary) upsets the finer relationships. Dark Blue = navy: good! Dark Green = brown. Not so good. Light Blue = Good! Light Purple = Pink. Not so good for the project. 

The standard color transforms tend to be flat adjustments across all the values. It has the effect of "graying" everything. This makes the darks muddy and the lights too bright. It still requires manual color-picking to get it right. 

Yes, the mathematics outputs harmonious colors. But they are not always aesthetically pleasing for the project. 
-- 
Benjamin Bertrand



On Jan 21, 2012, at 6:31 AM, Jon Rimmer wrote:

> On 21 January 2012 10:24, David Woolley <forums@david-woolley.me.uk> wrote:
>> Pete Boere wrote:
>>> 
>>> Are there any plans to implement color 'tweaking' functions in css?
>>> 
>> 
>> Your examples are manipulating technical parameters.  I would expect
>> designers to be interested in subjective behaviour, and therefore want to
>> specify the literal values that are subjectively right, not some algorithmic
>> approximation.
>> 
> 
> A use-case I have encountered a few times, and where these functions
> would be very useful, is providing theme-ability in a web application.
> End users or client employees need to be able to specify colors and
> have them used throughout a website. However, a design will often use
> a lot of different colors and gradients, and requiring the user to
> specify all of them is too burdensome. In fact, most of the colors
> used by a design will be variations on a couple of base colors:
> highlights, shadows, partial-transparencies, etc.
> 
> Having a way to specify a base color, and produce variations using
> these kinds of transformations makes it much easier to achieve this
> requirement. A designer defines the color relationships. Then the user
> simply selects one or two base colors, and everything else adjusts
> based on them. There are various online color scheme designers that do
> something along these lines [1].
> 
> The fact that this already exists in preprocessors seems like
> reasonable evidence that there is a need amongst some authors for this
> ability.
> 
>> The over the wire cost of these examples would be higher than sending the
>> literal, i.e. a preprocessor would be better.
>> 
>> I would think scripting interfaces would already cope with dynamic, client
>> side, manipulation.
>> 
> 
> The over the wire cost may be larger, but it doesn't necessarily
> follow that a preprocessor would be better. There are advantages in
> terms of simplicity of authoring, hosting and interchanging documents,
> that makes it desirable to reduce the need for preprocessors and
> client-side libraries when practical.
> 
>> 
>> --
>> David Woolley
>> Emails are not formal business letters, whatever businesses may want.
>> RFC1855 says there should be an address here, but, in a world of spam,
>> that is no longer good advice, as archive address hiding may not work.
>> 
> 
> [1] http://colorschemedesigner.com/
>