[Mapcss] Proposal: Drop css's ugly colour specifications

Thomas Davie tom.davie at gmail.com
Mon Feb 7 15:30:36 GMT 2011


On 7 Feb 2011, at 15:25, Sebastian Klein wrote:

> Thomas Davie wrote:
>> On 7 Feb 2011, at 09:12, Thomas Davie wrote:
>>> The css mailing list recently had a long discussion about hex codes and names being a really ugly way of dealing with colours, and arguing that they should be dropped in favour of rgb(r,g,b) and rgba(r,g,b,a) (along with potentially other colour spaces for print for example).  The conclusion was that there's a lot of legacy css out there that this would break, and a lot of html/css editors that would continue to produce broken code.  Because of this, they never changed the standard.  We have a far smaller problem here – our existing stylesheet base is much smaller, and hence perhaps have the chance to nip the problem in the bud now.
>>> 
>>> I propose that all colour specifications be replaced with the modern specifiers.
>>> 
>>> I also have a second proposal related to this.  CSS typically uses the range 0 to 255 even in these specifiers.  I'd like to propose that we use the cleaner 0.0 to 1.0 range.  This has the advantage of not exposing an implementation detail, though I acknowledge there's a disadvantage in deviating from what css does here.
>> Appologies for following up my own mail.
>> One further advantage of this proposal is that it cleans up the use of opacity: all over the place.  If users want non-opaque items, they can simply use an rgba colour.  If the colour is specified to multiply any image specified, then semi-transparent (or even colour variant) images are easily supported too.
>> The use of 0.0 to 1.0 appears to be consistent with the existing semantics of opacity: properties.
> 
> There are certain advantages to have opacity as an extra property. If you like to modify an existing default style and, e.g. make all filled areas transparent, this could be done like this:
> 
> area {
>  fill-opacity: 0.2;
> }
> 
> 
> At that point, the areas have different colors, of course.
> 
> Second, opacity is still needed for fill-image and icon-image, so for consistency it would be nice to have it for strokes and color-fills as well.

This all seems to be rather a cludge around a simple dilema – sometimes you want to multiply colours, sometimes you want to replace colours.

Your opacity replacement there is really a case of "multiply the opacity of the colour by 0.2", and can be generalised to "multiply the colour by rgba(1.0, 1.0, 1.0, 0.2)"

Similarly, fill-image and icon-image are again really a case of multiplying the colour of each pixel, and this is a great example of where multiplying by a whole colour would be useful – if I have a white icon, and want to represent different types of the same thing with different coloured icons, it would be very useful to be able to specify a colour-multiply of rgba(1.0, 0.0, 0.0, 1.0) to get a red one in one place; rgba(0.0, 1.0, 0.0, 1.0) to get a green one, and rgba(1.0, 1.0, 1.0, 0.2) to get a semi-transparent one elsewhere.

Is what's really needed a colour-multiply: property instead of opacity (but as well as a colour:) property?

Thanks

Tom Davie


More information about the Mapcss mailing list