- From: Jon Rimmer <jon.rimmer@gmail.com>
- Date: Sat, 21 Jan 2012 12:31:10 +0000
- 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 UTC