[Idea] Visual Picker - Making it easier to find the right element in the page

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.

4 Likes

On Stack Overflow I just saw a question that asks something like this. The question was how to determine which DOM element is causing the dimensions to increase for a parent element.

Sometimes it can be quite hard to answer this question.

I find Patrick’s idea to solve this problem very compelling. There are obviously many different use cases which could be solved by such a “visual picker”. It could be used to get to know where some white space comes from, to find out what makes up the dimensions of an element, how the layout of two elements are related, and similar issues.

The proposal to let it work similar to the existing element picker makes it consistent to what people are used to.

I can think of two ways how to enable such a visual picker:

  • A separate toolbar button
  • Pressing a modifier while the element picker is active

As there can be multiple elements involved, there needs to be a persistent way to display them. Patrick suggested a right click to do that. Since we’re already in “visual picker” mode then, a single click might already be enough.

Patrick also mentioned color-coding the nodes. Though instead of doing that within the markup view, the involved nodes could be hightlighted right within the page similar to how its done for the grid and flex highlighters. Hovering a node within the node info bar could then emphasize the highlighting of it. Clicking it would select it in the markup view.

It is important to clarify how the different nodes are involved in the inspected part of the page. E.g. a space may not only be caused by CSS but also by whitespace.

To provide the right information for all the cases is surely quite difficult but an initial implementation wouldn’t need to cover all of them. It could be extended later on.

I saw Patrick already created a meta-bug for this.

@jdescottes How to make progress in this direction? Should it be discussed further here? Should I create individual blocking bugs already?

Sebastian

1 Like