[Mapcss] Proposal: Drop css's ugly colour specifications
tom.davie at gmail.com
Mon Feb 7 15:26:03 GMT 2011
On 7 Feb 2011, at 15:17, Peter Wendorff wrote:
> Am 07.02.2011 14:41, schrieb Thomas Davie:
>> Given this, what do you think to the idea of dropping the opacity property and rolling it into the colour? If we keep the hex rgb format, this can be incorporated in the same way as it's being done in css3 – support #rrggbbaa and #rgba.
> Why again do you want to drop the opacity?
> I think, it's not a bad idea to be able to control it separately.
> If you see color:rgba(r,g,b,a); as a shorthand property of color:rgb(r,g,b); opacity:a; as shorthand properties are common in CSS it's additional useful as it's possible to change the opacity level with changing one property independently (opacity).
> I can specify something like:
> opacity: 0.5;
> where element 2 inherits from element1.
> Classical CSS is implemented in a different way, as a semi transparent color produces semi transparent background while opacity at an element produces the whole element as semi transparent (including text etc.).
> Perhaps that's an issue to think about further here; but as MapCSS mainly deals with graphics and not text, I'm not sure if I have enough knowledge about the current MapCSS idea here.
The reasoning for dropping opacity was simply to keep things orthogonal. Why have two independent controls when one will do it just fine.
I can see the advantage in your example, but if there's advantage there, is there also one by making all colour channels seperate? Essentially, what I'm saying is "what is the advantage in treating one and only one of the channels as a special case", it seems to be a recipe for corner cases.
I don't think the argument that css treats the colour as the background and the opacity as the alpha for the whole element works here, MapCSS specifies the colour of each element completely independantly (text seperately to the stroke, seperately to the fill etc).
More information about the Mapcss