Re: [svgwg] z-index rendering order not supported by any browser

> I suspect browsers have backwards compatibility concerns.

There shouldn't be an backwards compatibility issues as spec'd, except for possible rare cases of "zombie CSS" where authors had CSS rules that applied non-zero `z-index` values to SVG elements despite it not having an effect.  "Stacking contexts" in SVG layout would have very few side effects (does not change layout, only layering), and the default z-index layering, with or without stacking contexts, is the source order layering.

As I understood it, the main obstacle for implementation has been no one willing to tackle digging through all sorts of old code, that made all sorts of assumptions about rendering order matching source order, to find all the places that need to be updated.

> This feature is already marked at-risk. Should we drop it from SVG 2?

Unless we can get two implementer commitments—for implementing by the end of 2018—then, yes, we should defer to 2.1.

Which is disappointing to me, because this is a very important accessibility feature (being able to preserve a semantic and sensible DOM source order based on content, independent from drawing layers), and it is frequently requested [by web authors](https://twitter.com/search?q=z-index%20svg) who are surprised that `z-index` doesn't work with SVG groups and shapes.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/483#issuecomment-403334724 using your GitHub account

Received on Monday, 9 July 2018 01:27:05 UTC