I proposed this idea at some stage last year, but we didn’t get a chance to work on it then. I’d like a bigger group to discuss its merits before reconsidering it in the future.
Problem Statement
Here’s a common question people ask themselves when inspecting web pages:
Where is this extra space coming from?
People find it hard to locate the elements that contribute to a given location on a page. Often this location is an empty area that people are trying to debug.
This is especially true when the DOM tree is very deeply nested and many of the elements contribute a bit of the margin, padding or gap pushing elements apart.
Users of DevTools end up having to select many elements, one by one, each time looking at the CSS rules to determine what effect the particular element has.
The current element picker (the thing you use to select elements on the page) isn’t always helpful. Users can’t always select the thing they’d like to.
The current picker either selects an element that happens to be in front of the area they want to select, or this area is empty and they end up select a background wrapper.
Proposed Solution
The general idea here is to help people find the right HTML element(s) faster. The idea isn’t to solve the problem for them, but to point them in the right direction really fast.
Right now, finding these elements is a slow and frustrating process.
The element picker is only capable of selecting single elements that:
- Happen to be rendered on top of the z stack.
- Happen to have their border/padding/content area right beneath the cursor when the user clicks.
This unfortunately doesn’t cover all use cases. Users have gotten used to it as this is how pickers have always worked in all DevTools, but it’s suboptimal.
In order to select an empty space in the page, or pick an element that might be displayed behind a full page overlay, you need a smarter picker that is aware of what makes up things on the page.
The Visual Picker would let users click anywhere in the page, just like the Element Picker does, but would give access to all the elements that contribute to this particular position and why they do.
That means if 2 elements’ margins collapse, then both elements would be listed.
If a column gap exists between 2 grid items, then the grid container would be listed, with the grid gap being highlighted and the exact reason given.
The node info bar (the little tooltip that appears next to the cursor when picking an element in the page) could be re-purposed to show the reason why a certain area becomes highlighted in the page.
It could also be used to list multiple elements when more than one match the current location.
I started building a prototype last year as a DevTools extension to start exploring possibilities here: https://github.com/captainbrosset/visual-picker.
Ideas to further improve this solutions include:
- Possibly number elements listed in the node info bar so that pressing that number would select the corresponding element.
- On right-click, we could show a persistent info bar with the elements and allow the user to click one of them, like in Photoshop.
- Color-coding nodes in the markup-view to show they are involved.
- Filtering the markup-view to only show the matching elements.
- Being able to pick grid gaps, flex gaps, justify-content/items and align-content/items space. Node info bar would become super good at explaining why certain things become highlighted on hover (like a gap between 2 flex items).
I’d love to hear what people think of the idea, especially if you think it would actually solve a problem for you as a DevTools user.