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

Thomas Davie tom.davie at gmail.com
Mon Feb 7 13:41:01 GMT 2011

On 7 Feb 2011, at 13:33, Steve Bennett wrote:

> On Tue, Feb 8, 2011 at 12:26 AM, Thomas Davie <tom.davie at gmail.com> wrote:
>> 1) The css guys admit they would rather use something nicer here, but don't want the disruptive change.
> That's an argument by authority or something. A meta-argument?

Good point, scratch that one

>> 2) We're much more likely to be trying to support styles that work for paper maps and wanting really acurate nice colours than css is.
> An argument for additional color specifications, but not against
> dropping #abc format.
>> 3) The CSS mechanisms (even their version of the rgb(a) constructor) don't support > 8 bits per channel.
> Ditto.


>> 4) The 0-255 range is an abstraction leak.
> IMHO it's more a legacy convention. Is there even an underlying
> implementation detail somewhere that uses 8 bit-per-channel colour? Do
> you know? I sure don't. There's definitely no way those 8 bits make it
> to my monitor unscathed...

Sure there is, in a typically OpenGL implementaiton they'd be packed into an 24 bit RGB colour value and pushed straight onto the graphics card.  Though I agree that's a rare situation.  However, colours being specified as 8 bit integers per channel is very common in graphics formats and APIs.

>> 5) Cartographers typically don't think in terms of 0-255 ranges, they think in terms of 0-1 or 0-100.
> Right, so we have two different audiences with different needs. Us web
> geeks think in hex. Map people don't. We need more information to work
> out what to do with that information.
>> Steve brought up that 0-100 might be nicer than 0.0-1.0, which I can see.  The only slight issue I might have with that is that if an-ex-csser saw rgb(65,22,98) he might think "ah, that's clearly the same as css", while if he saw rgb(0.65,0.22,0.98) he might think again.  I don't really find this a very compelling argument though.
> Heh, I do - I didn't think of that. There's no way we want
> rgb(65,22,98) to be ambiguous (or to be perceived as ambiguous). If we
> support a decimal format it would have to be different, like
> rgb100(65,22,98).

That's a very clean idea, and neatly supports both audiences you discussed above, can we do that? :)

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.


Tom 'Beelsebob' Davie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/mapcss/attachments/20110207/e50b4a5d/attachment-0001.html>

More information about the Mapcss mailing list