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

Steve Bennett stevagewp at gmail.com
Mon Feb 7 13:33:53 GMT 2011


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?

> 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...

> 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).

Steve



More information about the Mapcss mailing list