Add z-index

[tmcw]

The more I look at attachments/instances/normal rules, the more it seems like there's a potential to add z-index to Carto, and it might be more user-friendly to people than having stacking determined by position.

Thoughts @springmeyer @gravitystorm @ajashton

[ajashton]

So there are 4 groups within which z ordering happens: Layer, Style (attachments), Symbolizer (incl. instances), and database order. Reordering elements within each of these groups is easy. Trying to make the z-index jump outside this system would be difficult. Eg say I have #top_layer above #bottom_layer, and in #bottom_layer I have ::foo and ::bar. Would I be able to use z-index to have ::foo render above #top_layer, but ::bar render below? The XML tranlsation for this would require making a duplicate (& invisible to the user) #bottom_layer that is above #top_layer. I don't think we'd want to do this, but this may be what users expect of the feature.

It would be nice to not have to rely on ordering of the style code for attachments and symbolizers though. One idea of how this could work:

• Leave Layers alone, so that part of TileMill can still work like Photoshop/Illustrator/Inkscape etc.
• have a z-index property which affects the ordering of attachments within a layer
• have symbolizer-specific properties, eg line-z-index, for affecting order of symbolizers (including instances I guess) within an attachment/style.

[gravitystorm]

I like @ajashton's proposal. While I do like that attachments and instances have an inherent ordering, I've found it gets frustrating with complex nested rules. Having an explicit z-index as he describes would be useful, so long as the default case continues to have a reliable order.

I've previously thought about making attachments/instances ordered alphabetically, so that they are robust to refactoring of the style, but I think that cramps the choice of names. I tend to use a/b/c/d for many things, but I do like to be able to call things "::outline" without checking a thesaurus for things beginning with "a"!

So I'm in favour of at least having an override, as described, for for when the default order-by-position isn't appropriate.

[springmeyer]

While I do like that attachments and instances have an inherent ordering, I've found it gets frustrating with complex nested rules. Having an explicit z-index as he describes would be useful, so long as the default case continues to have a reliable order.

^^ my sense is the same as andy's

So, +1 to keeping current behavior which is order based on position in stylesheet - now better understood via the regression uncovered in #247 - and when we have time adding a z-index override seems valuable.