Repository navigation
z-index rendering order not supported by any browser #483
Description
Spec text
https://svgwg.org/svg2-draft/render.html#ZIndexProperty
Failing test
https://wpt.fyi/results/svg/rendering/order
This feature is already marked at-risk. Should we drop it from SVG 2?
I suspect browsers have backwards compatibility concerns.
Activity
birtles commentedon Jul 9, 2018
@jwatt were we still looking at doing this?
AmeliaBR commentedon Jul 9, 2018
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-indexvalues 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.
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 who are surprised that
z-indexdoesn't work with SVG groups and shapes.Defer z-index support from SVG 2
jwatt commentedon Jul 10, 2018
@birtles I'd like to do it but it's not on any roadmap currently. I don't imagine we'll implement it this year.
TheShaperr commentedon Mar 3, 2020
Almost two years later, any update?
[svg] Mark the z-index test tentative (#62733)
Bug 2072500 [wpt PR 62733] - [svg] Mark the z-index test tentative, a…
Bug 2072500 [wpt PR 62733] - [svg] Mark the z-index test tentative, a…