On Wed, Sep 29, 2010 at 3:36 AM, Komяpa <[email protected]> wrote: > Hi, > nice to see you here too :) > > 2010/9/29 David Winslow <[email protected]>: > > > From a brief perusal of the documentation on the OSM wiki, I see the > > following major differences between my take on CSS-for-maps and MapCSS: > > square brackets for expressions vs. eval('') > > Well, I'd want to explain my vision of why it's called eval() and > better to be so. > There are renderers in different languages, including Python, > ActionScript, tcl, JS and so on. Hard for me to imagine something that > will execute at roughly the same speed as native eval() in those > environments. That's why MapCSS eval ( > http://wiki.openstreetmap.org/wiki/MapCSS/0.2/eval ) syntax was > designed in a way that those languages can just take as-is and > execute, providing a faster development and nice features on the cost > of some "security issues". At least for Python there are "restricted > eval" implementations that can't do anything except for what author > allowed. > > MapCSS is not the only who does that; http://cartagen.org/ has the > same idea in their maps language. > > In case someone cares a lot of security, he is free to reimplement a > runtime for eval() expressions that won't do any harm for sure.
I understand that MapCSS has (so far) been developed with ease of implementation in mind. My design goals have been slightly different (create a CSS language which exposes as much as possible of vector styling functionality in SLD). I have been thinking for some time about providing a restricted filter syntax that is more CSS-like, and I like the eval() notation as opposed to []. Currently I am thinking about adding eval() and cql() functions, or something along those lines, to expose the two expression languages. Perhaps the cql function should have a prefix like -gt- to indicate behavior not adopted by the general mapcss community. > repeated properties (inspired by CSS3; > > see http://www.w3.org/TR/css3-background/#layering) vs. repeated > property > > lists. > > Nice idea. Things that stop from taking it as-is is that > 1) we've got comma-separated lists for dashes - how to stack them? > 2) cascading becomes somewhat undefined. i.e.: > .... {linecap:butt,round; width: 2,3} > .... {width:2 } > what color and how many lines will we get if both are applied? 1) I represent dash arrays using whitespace-separated lists, so the commas work as usual. Same for other list-ish properties (font-family is the only one that comes to mind...) 2) There is a "key" property for each type of rendering: - "stroke" for line strokes (the stroke color/image) - "fill" for area fills (the fill color/image) - "mark" for point markers (the icon or symbol) - "label" for text labels Each of these properties "activates" a particular type of rendering, so if you specify stroke-opacity, stroke-width, and stroke-linecap, but omit stroke itself, no lines will be rendered. Additionally, repeated values of these key properties activates repeated rendering. Any "extra" values for non-key properties are omitted; property lists that are shorter than the "key" property list will be repeated as needed to pad out the list. Example: * { stroke: red, blue, green; stroke-width: 8px; stroke-opacity: 100%, 80%, 60%, 40%, 50%; } is equivalent to * { stroke: red, blue, green; stroke-width: 8px, 8px, 8px; stroke-opacity: 100%, 80%, 60%; } > > the concept of "well-known marks" (cribbed from GeoServer's native > styling > > language, SLD, see > > > http://docs.geoserver.org/stable/en/user/styling/sld-cookbook/points.html#simple-point > ), > > basically built-in simple geometries which have their own styling > attributes > Nice. For now we've got only square and circle for nodes, emulated as > if it was a zero-length horizontal line (just two linecaps near one > another). Well, well-known marks in SLD and thus my CSS have a couple of interesting properties: - dynamic styling like normal features - can be used anywhere an image goes (ie, fill and stroke patterns as well as point markers). This makes them a lot more flexible than static images... but also doesn't help my case for inclusion in mapcss 0.2. > But, seems to me that this idea (to extend that list) is probably not > for 0.2 mapcss - 'til now it was more-or-less happily done with > images. We still don't have a reference renderer that supports 100% of > mapcss 0.2, though Kothic is near to that :) -- > Darafei "Komяpa" Praliaskouski > OSMF BY Team > xmpp:[email protected] <xmpp%[email protected]> mailto:[email protected] > > _______________________________________________ > Mapcss mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/mapcss >
_______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
