Talk:MapCSS

• check also the MapCSS Proposals.

Zoom Levels

Richard, one question: how are the MapCSS styles related to the zoom level of the map? One of the features I implemented for Kosmos rules is the ability to set a zoom-dependent value for a style (Kosmos_Rendering_Help#Zoom_Factor_Values), example:

Width=1:1;9:1.5;17:6

means that the width used by the template will be 1 pixel on zoom level 1, 1.5 pixels on zoom level 9 and 6 pixels on zoom level 17. Everything in between is interpolated, so for example on zoom level 12 the width will be 3.1875

Since Kosmos GUI displays maps interactively, it allows a continuous zoom level settings, not just as integral values. Also, I wanted to avoid having to maintain different rulesets for different zoom levels.

I am also looking for some CSS-like styling format that would be more flexible than the Wiki-table rules Kosmos now uses, but I want to address these kinds of issues.--Breki 12:01, 3 September 2009 (UTC)

At its simplest, MapCSS lets you write rules that applies at certain zoom levels, like this:

way[highway=primary] { color: red;} 
way|z11-12[highway=primary] { width: 3px;} 
way|z13-14[highway=primary] { width: 5px;} 

But what I'd like to add is some form of 'eval' operator, so that you can dynamically calculate from tags and zoom levels. So you'd be able to do something like this:

 way[highway=primary] { color: red; width: eval('20-$zoom'); }

The calculation could of course be a fair bit more complex.

Would that do what you want? --Richard 17:10, 3 September 2009 (UTC)

If the eval function would be extendible enough to cover the '1:1;9:1.5;17:6' syntax, then this would be great :). Or perhaps leave the freedom for individual implementations of MapCSS-based engines to support custom extended syntaxes (I know, this is not ideal, since the idea is for these styles to be interoperable between different engines, but still...) --Breki 17:49, 3 September 2009 (UTC)

@import - use vs. "normal" CSS

In CSS for HTML, the media type at the end of an @import statement is the output media, not the input media. I can see a need for being able to include output media-specific rules (e.g. print vs. screen vs. mobile), so should we follow the W3 convention? Jonathan Bennett 13:55, 14 October 2009 (UTC)

Whitespace in selectors

This is a compatibility-with-W3C-CSS point.

In the page is says "We can be liberal in how we treat white space". Up to a point, Lord Copper.

The quantity of whitespace is irrelevant (1 space vs. three tabs, a CR and a space), but the presence or absence of whitespace in selectors is significant.

For instance:

way .highway

means "Any descendant of a way where the descendant has the class 'highway'", whereas:

way.highway

means "Any way with the class 'highway'". The latter is probably what you want, since the former will only match nodes with a highway=* tag. Jonathan Bennett 12:31, 30 November 2009 (UTC)

Section "Other projects with customisable vector rendering"

In my view this section doesn't make sense here. If nobody complains I will remove it in 2 weeks. --Saerdnaer 14:13, 13 November 2011 (UTC)

Complain! ... when you are dealing with selfmade vector rendering rules, it is always worth to look at other standards as well. So I would like to keep these information there. --Stephan75 15:23, 1 January 2012 (UTC)

mapcss.org

It appears that mapcss.org is no longer functioning. Anyone have any knowledge of what happened to it? Glassman (talk) 02:04, 29 June 2020 (UTC)