W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: Color tweaking functions

From: Jon Rimmer <jon.rimmer@gmail.com>
Date: Sat, 21 Jan 2012 12:31:10 +0000
Message-ID: <CA+ZDCiCau+d+vmYE=v9z8vmtxaHeh9d395LM5b8HrBO8tp5RZw@mail.gmail.com>
To: David Woolley <forums@david-woolley.me.uk>
Cc: Pete Boere <pete@the-echoplex.net>, www-style@w3.org
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/
Received on Saturday, 21 January 2012 12:31:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT