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
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
