[Mapcss] MapCSS 0.2 finalization and cleanup
phaaurlt at googlemail.com
Sat Apr 28 12:49:54 BST 2012
On 04/28/2012 10:59 AM, Komяpa wrote:
> Hello everyone,
> We all know everyone is willing to make their renderer the best one.
> Everyone has own purpuose - some are targeting on speed, some are
> willing to provide good editing experience, some want to just show
> something to the user...
> So, what do I propose:
> 1. Count and list active renderer developers. Those who really have
> time to fix minor things and want to have a badge "Supports MapCSS 0.2
> 2. Set up a deadline. Something real, like 1st of June (or July),
> 2012, when a spec will be marked "final", and all things post this
> date will go to further versions/extensions/discussions.
> 3. Chop the current draft to really really basic things. As we see,
> almost noone supports extrude, not everyone has support for eval(),
> .pseudoclasses aren't widely used, shields aren't implemented in most
> software, set and exit; ...
> So, we make a list of core features that everyone supports or will be
> able to support in the nearest time.
> 4. Split all the stuff that's chopped from 0.2 spec into some separate
> features for further discussion.
> 5. Draw beautiful badges "Powered by MapCSS" for sites and renderers.
> Are there any supporters for this initiative? :3
> Lately, I've tried to make a stylesheet that will look the same in
> kothic, komap, potlatch and josm, and wasn't able to do it, because
> even basic things like casing-width are handled differently in all of
> I just want to have a strict subset of MapCSS that will work
> everywhere for sure. :3
The openness of the MapCSS language is great, because it invites people
to take an active part in the development. But one downside is the
fragmentation of the language. I think we are at point where we should
fix at least a subset of the specification.
The wiki page  has lots of stuff that is supported by one renderer
only, or implemented inconsistently.
In my opinion, a better starting point would be, to look at the actual
implementations and to find de facto standards. If one renderer
deviates, we should talk it through and see if we can come to an
agreement. If not, then postpone the issue.
In the process, we could also fill some gaps in the specification draft,
e.g. what does "|z12" mean exactly, what is the default position for
node text labels, etc...
There are two orthogonal goals:
* avoid fragmentation
* define a subset, such that implementers can be confident and say: "I
support the full specification of MapCSS x.y"
More information about the Mapcss