On Tue, Feb 8, 2011 at 12:26 AM, Thomas Davie <[email protected]> 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 _______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
