[Mapcss] Development of MapCSS?

Tom Davie tom.davie at gmail.com
Wed Mar 6 09:06:34 UTC 2013

On 6 Mar 2013, at 08:49, Martin Vonwald <imagic.osm at gmail.com> wrote:

> Hi!
> 2013/3/5 Andrew Shadura <bugzilla at tut.by>:
>> Hello,
>> On 5 March 2013 14:02, Martin Vonwald <imagic.osm at gmail.com> wrote:
>>>> On Mon, 4 Mar 2013 11:04:48 +0100
>>>> I'm not particularly happy with what's happening with MapCSS. It's
>>>> understandable when certain software doesn't implement some features,
>>>> as sometimes there may be technical or other obstacles for that. When
>>>> features are implemented a very different way, or implemented without
>>>> prior discussions, this leads to chaos. And that's what we have now.
>>> I guess that one of the reasons for this "chaos" is the slow (or not
>>> at all) progress in the MapCSS specification. Tagging is evolving fast
>>> and we need much more sophisticated rendering possibilities.
>> It's slow because nobody's doing it. When I say nobody I mean 0 (zero,
>> naught) persons. If a discussion started, some progress would be
>> visible.
> I understand. Usually there's a reason for such a situation. But as
> I'm not involved (and never was) in MapCSS development I can't name
> that reason.

To be honest, the original reasoning was more on the money.  Some simple examples include stuff like child selectors.  JOSM and OSP implement them because they are extremely convenient and powerful for creating styles.  Unfortunately, they also destroy any ability to cache styles given certain tag sets on objects, and destroy performance, which is a major concern when you're trying to write your renderer (for example) in Javascript.

>>>> In my opinion, JOSM implements MapCSS in a very bad way, and its
>>>> extensions are extremly non-systematic and against the spirit of
>>>> CSS-like languages at all and MapCSS in particular. Function naming
>>>> is very strange and is not easily readable.

Personally, I think the big issue here is actually that people think that MapCSS should be CSS like.  The goal should be to make a language that is clear at describing map styling.  Not a language that superficially looks a lot like another language that's already known for being crap at describing web styling.

>>> Maybe it is a "very bad way" but at least it is a way. Pure MapCSS has
>>> no way at all for such monstrous styles like mine.
>> Sure, as nobody (zero people) has asked for those features. No
>> proposals, no discussions, nothing. Just work behind closed doors.

OSM is a do-ocracy ;)

> Here we have a problem. Lets look at my situation: I'm writing a style
> for JOSM. Actually it is my second style after some playing around
> with another minimalistic one, so I don't have much idea of the
> situation. I encounter some problems while implementing and so I ask
> on the josm-dev if something was possible or not. Shortly after that
> some new functions are implemented in JOSM.
> So who's the "bad guy" now? Is it me, because I shouldn't ask on
> josm-dev but on this mailing list? I had no clue about this mailing
> list. Is it the josm developer, because he implemented something
> without discussing it on this mailing list? He just provided some
> valuable features.
> And while we try to figure out who's to "blame" we have a short look
> at the number of participants on this discussion. It's me and you.
> Maybe that's the real problem - lack of interest. A short look at the
> history of http://wiki.openstreetmap.org/wiki/MapCSS/0.2 and its talk
> page seems to confirm this.

Hopefully that should indicate that I have been involved in the discussion too.  Personally, I'm of the opinion that MapCSS is in *very* early stages of development, and we're still discovering all the ways in which current MapCSS can't style things we want to style.  Because of that, I think it's entirely reasonable for individual implementers to experiment with ways of supporting styling these features.

>>>> I think that it's a good time to put all information about various
>>>> extensions into one big table and try to unify and systematise them.
>>> Here we agree. But - and that's a big but - how intend you to get all
>>> developers of MapCSS renderers on one table and agree on a new,
>>> improved specification? And preferable not until 2016 but until - lets
>>> say - end of march? That's the real problem here.

Komzpa actually did succeed in doing this pretty much a good few months ago.  The intention was to try and get everyone to implement fairly similar feature sets.  IIRC, the result was that OpenStreetPad gained support for a bunch of things, but no one else's implementation really moved much closer to each other unfortunately.

>> Why not? This is an open mailing list, everyone's free to start the discussion.
> Starting the discussion is not the problem. Getting people to take part it is.
> I still think that a common style language is very important and
> should be our goal.

Agreed, but I'm not convinced that that means we need to tell people they're not allowed to experiment, extend, and improve what we already have.


Tom Davie

More information about the Mapcss mailing list