Bug combining multiple media queries

[plepe]

If I combine multiple media queries (using the comma syntax) I get a stack trace on the console. In fact, the media query is copied from the example page:

@media (min-josm-version: 6970) and (max-josm-version: 7014), (user-agent: myEditor) {
area[building] {
  fill-color: red;
}
}

generates:

WARNUNG: Mappaint-Stile in '/home/skunk/code/mapcss-examples/test-media.mapcss' enthalten Fehler: Encountered " <PP_SOMETHING_ELSE> ", "" at line 6, column 61.
Was expecting one of:
    "and" ...
    <PP_NEWLINECHAR> ...
    <PP_WHITESPACE> ...
    "/*" ...
    "{" ...
    "," ...
    
Fehler: org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.ParseException: Encountered " <PP_SOMETHING_ELSE> ", "" at line 1, column 61.
Was expecting one of:
    "and" ...
    <PP_NEWLINECHAR> ...
    <PP_WHITESPACE> ...
    "/*" ...
    "{" ...
    "," ...
org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.ParseException: Encountered " <PP_SOMETHING_ELSE> ", "" at line 6, column 61.
Was expecting one of:
    "and" ...
    <PP_NEWLINECHAR> ...
    <PP_WHITESPACE> ...
    "/*" ...
    "{" ...
    "," ...
    
	at org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.MapCSSParser.generateParseException(MapCSSParser.java:3022)
	at org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.MapCSSParser.jj_consume_token(MapCSSParser.java:2903)
	at org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.MapCSSParser.pp_media(MapCSSParser.java:266)
	at org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.MapCSSParser.pp_black_box(MapCSSParser.java:214)
	at org.openstreetmap.josm.gui.mappaint.mapcss.parsergen.MapCSSParser.pp_root(MapCSSParser.java:107)
	at org.openstreetmap.josm.gui.mappaint.mapcss.MapCSSStyleSource.loadStyleSource(MapCSSStyleSource.java:195)
	at org.openstreetmap.josm.gui.mappaint.MapPaintStyles$MapPaintStyleLoader.realRun(MapPaintStyles.java:329)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:82)
	at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:150)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

[bastiK]

In 7277/josm:

fixed #10210 - Bug combining multiple media queries

[bastiK]

Thanks for testing & reporting!

[plepe]

Perfect :)

By the way. I think, that discussing MapCSS improvements on the mapcss-mailinglist (​http://lists.openstreetmap.org/listinfo/mapcss) are quite tedious. I'd like to try if proposals in the OSM Wiki are an idea. I created two proposals, including @media queries, see ​http://wiki.openstreetmap.org/wiki/Category:MapCSS_Proposal . I haven't announced them yet on the mailinglist, but maybe you'd like to have a look at it.

[bastiK]

Nice, I think it is a good approach to prepare a proposal in the Wiki!

One comment for mapcss-version. It may be better to enclose the value in quotes, as it should be syntactically an expression - the same as the right hand side of an instruction inside a declaration block. Unless you add special handling, 0.2 would be parsed as floating point. If it is a string, you can move the logic to another function, after the parser has done its work.

Another point for object-z-index: The main idea was, that you can have a complicated arrangement of geometric elements, e.g. a speed limit sign which is modeled with white and red circles and a text element in the center. Now if two speed limit signs are close together and overlap, you like to prevent, that the elements interleave in a strange way. Instead, the speed limit sign for one node should be treated as one unit (as if it was an image) and drawn completely on top of the other. This cannot be achieved with z-index alone and therefore, object-z-index was introduced. The pseudo-code would be something like:

for zi in -10..10
  for o in osm-objects
    for ozi in -10..10
      draw elements for o with z-index zi and object-z-index ozi

In JOSM, this is done ​here. I would say that object-z-index is nice to have, but not essential for the proposal.

Let's see if there is still someone alive on the mailing list. :)