948364 - CSS z-index highlighter

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Patrick Brosset <:pbro>]

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.

Comment 1

[Victor Porof [:vporof][:vp]]

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.

Comment 2

[Joe Walker [:jwalker]]

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.

Comment 3

[Victor Porof [:vporof][:vp]]

(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.

Comment 4

[Joe Walker [:jwalker]]

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.

Comment 5

[Patrick Brosset <:pbro>]

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/)

Comment 6

[Joe Walker [:jwalker]]

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).

Comment 7

[Victor Porof [:vporof][:vp]]

(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.

Comment 8

[Patrick Brosset <:pbro>]

From tweeter: https://twitter.com/JoeWSCode/status/483573261205520384
"can devtools highlight the stacking context(s) a given element sits in? would be so useful!"

Comment 9

[Patrick Brosset <:pbro>]

s/tweeter/twitter

Comment 10

[Tim Nguyen :ntim]

We could use a material-design like shadow to designate depth.