On 7 Feb 2011, at 13:06, Jonathan Harley wrote: > On 07/02/11 12:21, Steve Bennett wrote: >> Ok, actually that leads to a more compelling argument: the #abcdef >> format does sort of trap MapCSS within the website world, whereas it >> has every right to be used for print maps that have never seen a >> browser. (But then, allowing both #abcdef and rgb(35.672,99.99,0) >> achieves that...) > > Isn't the point of having a CSS-like syntax for map styling, to be familiar > to web developers who've used CSS? > > In my experience, most web developers find learning CSS hard, and many resist > spending any more time on it than necessary to accomplish the task at hand. > Surely making mapcss look like CSS, but then behave differently at key > points, is the worst of both worlds.
Yes and no, As I've understood it from various people the approach that's been taken is to be like CSS *where it's appropriate*. There seem to be some compelling reasons why we'd not want to stick with what css does here: 1) The css guys admit they would rather use something nicer here, but don't want the disruptive change. 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. 3) The CSS mechanisms (even their version of the rgb(a) constructor) don't support > 8 bits per channel. 4) The 0-255 range is an abstraction leak. 5) Cartographers typically don't think in terms of 0-255 ranges, they think in terms of 0-1 or 0-100. 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. Tom 'Beelsebob' Davie _______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
