[Mapcss] Stacked rules question

[Sebastian Klein]

Sebastian Spaeth wrote:
> On 2010-07-07, Richard Fairhurst wrote:
>> Sebastian Spaeth wrote:
>>> [things about z-index]
>> Well, the z-index inheritance stuff is probably the thing I got most  
>> wrong with the original spec. :)
> 
> Pfeww, I was doubting my sanity, so happy to hear that :). Yes, let's work it out.
>  
>> My current thinking is that we start with:
>>    way[highway=footway]::highlight  { width: 3; z-index: 2; }
>>    way[highway=footway]::centreline { width: 2; z-index: 3; }
>>    way[highway=footway]::centreline { color: green; }
>  
>> In other words, you can define a new stroke(/fill) using the CSS  
>> subpart (double colon) syntax.
> 
> Arrg, that is another part that I did not get and wanted to postpone to
> another day (life?) :-). OK, so subparts we have. Are the names for
> subparts arbitrary labels? If yes, things are much clearer again.
> 
>> Here we have two strokes. One  
>> (highlight) is width 3, z-index 2, green; the other (centreline) is  
>> width 2, -index 3, green.
> 
> Hold on, why is highlight green? It is not defined above, right? Green
> only applies to "centreline". Would that work as intended?
> 
>     way[highway=footway]::highlight  { width: 3; z-index: 2; }
>     way[highway=footway]::centreline { width: 2; z-index: 3; }
>     way[highway=footway] { color: green; }
> 
>> Let's say we want to apply opacity 0.5 to all the ways above. Should we say
>> way[highway=footway] { opacity: 0.5; }
>> way[highway=footway]::* { opacity: 0.5; }
>> I'm tempted towards the latter.
> 
> I see your point, but I would lean towards the first option, I see these
> as filters in a hierarchical stack that filter elements gradually out. So each of
> the bullet points below is a superset of elements to the next:
> 
> - way
> - way|z12
> - way|z12 [highway=footway]
> - way|z12 [highway=footway][horse=yes]
> - way|z12 [highway=footway][horse=yes]::centreline
> 
> Your proposal would make the second last line behave different from all
> the others. It would make sense to support only __unnamed__ subparts
> somehow, but that could happen with
> way [highway=footway]:: {color: strawberry;}
> 
> I would agree that supporting "::*" would make sense and is very
> intuitive. In the end, I am fine with both, but find your preferred
> solution a bit awkward for the above reason.

It might be a good idea to stick to the css spec for the most part [1] 
and introduce new syntax and semantic only where it is needed. The 
canonical example for subpart is

   p::first-letter {...}

which addresses the first letter of the paragraph, but you can still 
style the entire paragraph (including the first letter) with

   p {...}.

This would suggest to use the interpretation favoured by Sebastian Speath.

The difference here: The first letter of the paragraph is always 
visible, but a highlight of a way is an optional/exceptional feature.


For simplicity, I would prefer to write

   way[highway=footway] {width:3; color: orange; antialiasing:none}
   way[highway=footway][bicycle=yes] {dashes: 2, 2}
   way[highway=footway][bicycle=yes]::highlight {width:5; color: blue}

This should draw non-antialiased orange way for normal footway. If it 
has the tag bicycle=yes, it should be dashed and have a blue highlight 
(also not antialiased).

So my interpretation would be: way[highway=footway] applies to the way 
element itself (whatever that is) and all its subparts (::centerline, 
::highlight, ...) However, some subparts are defined as default 
(::centerline) and others as optional (::highlight, ... the rest).

Optional subparts are not rendered unless they are declared. (I.e. there 
exists at least one selector for them.) Each subpart can have a 
different default value. (E.g. default z-index should be lower for 
::highlight than for ::centerline.)

Does this make sense? Basically, I'm fine with any solution that removes 
the "magic" from z-index property. This would make stacked rules (way 
{...} {...}) obsolete, right?


[1] <http://www.w3.org/TR/2005/WD-css3-selectors-20051215/#pseudo-elements>

--
Sebastian