[Mapcss] Strings and Keywords
Sebastian Klein
bastikln at googlemail.com
Mon Jul 19 14:35:18 BST 2010
Komяpa wrote:
>> I think there is an agreement to start from css (because it is widely
>> used and well supported) and only deviate when there is a reason.
>>
>> In this case the reason could be that it is easier to implement. ;)
>>
>> In css it is an error to write
>> color: "red";
>> because red is a keyword:
>>
>> http://www.w3.org/TR/CSS21/syndata.html#keywords
>
> could you please provide a case when quotation marks are needed?
E.g. values with white spaces:
http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
>>>> Another example would be the yes keyword in conditions. I'd say
>>>> [oneway=yes] applies to a oneway tag with value yes, true or 1, but
>>>> [oneway="yes"] matches the literal
>>>> value "yes", only.
>>> My opinion on this is that we shouldn't do any magic, and that "yes" should be
>>> the only "yes" but not "1" or "true". For "magic" comparison I'd write
>>> something like boolean(oneway)=true, like in eval().
>> It is more or less a part of MapCSS 0.1 and 0.2. I don't like it that
>> much either, but with quotes it would at least be possible to suppress
>> the magic.
> I think that we should drop this magic from spec. If user wants to
> match all the =yes, =true & =1, it's up to him to write that in
> stylesheet.
I already asked Richard to remove it, but at that time he was still in
favour of the yes magic. An alternative would be the JOSM search syntax:
There you can write
onway?
as a short cut for (oneway=yes | oneway=true | oneway=1).
Generally it makes sense to have something like this, because "yes" is
standard and most frequently used, but "true" and "1" are considered
valid synonyms for all tags that accept "yes".
Sebastian
More information about the Mapcss
mailing list