Andy Allan wrote: > But I see Cascadenik isn't in that list, which is the point I'm trying > to make. When you invented another "CSS-like language for describing > map styling" there already was a "CSS-like language for describing map > styling", and it's a great shame that nobody made any effort to make > the two compatible. Take even trivial issues like "line-cap" vs > "linecap", or "butt/round/square" vs "none/round/square". Neither > MapCSS nor Cascadenik even match SVG in this case! The various colors > can be rgb() or even now rgba() in one but only hex in the other, > shield-file vs shield-image, and so on and so on[1].
Sure. So - please do sign up to the mapcss mailing list and say what you think needs fixing. Like I say: it's young. If wrong decisions have been made we shouldn't pigheadedly stick with them. If there's something that can be fixed while remaining just as CSS-like (or more so), we should do so. I'm reasonably confident that the fundamentals are right and I'd hope the uptake demonstrates that; the one thing that was clearly completely dumb in the initial spec was the z-index magick, and thanks to smart thinking by Komzpa and Paul Hartmann, that's been fixed in 0.2. But, again, that's certainly not to say everything is perfect. FWIW linecap is largely from SVG: we call it "linecap" rather than "stroke-linecap" because (to be CSS-like) we don't use the "stroke-" prefix. If there's no good reason for MapCSS to use the "none" value rather than SVG's "butt", we should move to "butt". Heheh. He said "butt". (Incidentally, I missed out from my previous posting one thing that I did want to say: my one disappointment with all of this is that Maperitive doesn't use MapCSS or indeed anything of that ilk.) cheers Richard _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
