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.
Sebastian
pgpPNXdv6B19a.pgp
Description: PGP signature
_______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
