This is part of the meta bug 942176 which aims at providing information overlays for various CSS properties in order to explain how/why they apply. The goal of this bug is to find a way of helping understand why certain elements get stacked the way they do on the z axis. My view on this is that the CSS z-index property is often times misused and the concept of stacking context isn't widely known. The devtools could help by somehow highlighting elements that are part of the same stacking context as a given inspected element, and either color them or give them numbers explaining the current order and why it is so. One idea could be, on hover of a z-index property in the rule view, to highlight the element that forms the stacking context for the currently selected element, as well as highlight all other child elements part of that context and label them with their order of appearance in the HTML and z-index if any. This is, as you can see, a very rough idea, but it makes sens as part of meta bug 942176 and I think it could definitely help if done well.
While ago we had the idea to use Tilt to stack DOM nodes based on their respective z-index, not depth in the DOM tree. Obviously, using the exact z-index value for determining the location along the z axis wouldn't be always nice, because of obnoxious values like 9999..., but at least stacking the nodes based on ascending z-index values would work.
Victor, how hard would it be to have a tilt-on-hover thing where tilt is enabled while hovering over a z-index property in the rule view. I'm guessing that we'd need to flip to some known perspective with little or no animation, in a fairly quick time.
(In reply to Joe Walker [:jwalker] from comment #2) Anything in that realm, and also displaying a 3D view for only a node or smaller parts of a page, is trivial. The only real blocker is bug 937166, for which there's no priority set yet. Alternatively, I could try to make Tilt's renderer headless so that it can receive arbitrary nodes or points to draw, but that would require a similar amount of work as bug 937166.
A z-index sorted tilt-on-hover would be all sorts of awesome. It validates Tilt, and adds to a rapidly growing list of rule view helpers. I wonder if we could cope with obnoxious z-indexes like 9999 if we plotted the gaps on a log scale? We could choose the base of the log depending on the variation between the biggest and smallest gaps.
In my opinion, stacking nodes based on ascending z-index is enough, we don't need to plot them according to their actual value. I think the main question this should answer is "why is this element below that other one", and it should do so by showing they're not part of the same stacking context and therefore even choosing the highest z-index isn't going to make any difference (i.e. http://jsbin.com/USuNolE/1/)
I think you're right. Stacking the nodes in simple order is actually better than a proportionally spaced approach because it points out that 9999 is no 'higher' than 9 (assuming the next highest is 8).
(In reply to Patrick Brosset [:pbrosset] from comment #5) > In my opinion, stacking nodes based on ascending z-index is enough, we don't > need to plot them according to their actual value. > I agree with this.
From tweeter: https://twitter.com/JoeWSCode/status/483573261205520384 "can devtools highlight the stacking context(s) a given element sits in? would be so useful!"
We could use a material-design like shadow to designate depth.
You need to log in before you can comment on or make changes to this bug.