There are some common UX patterns in DevTools, such as linking from one place to another, loading states, or dialogs. Please refer to this guide if the pattern you intend to use can be found here.
Please also note that while some patterns can be summarized into a component, this guide focuses more on the end-user experience than the actual implementation.
Overlays are visual aids that are superimposed on the webpage you're inspecting. These overlays provide extra information or highlight specific aspects of the page to help you with debugging and development.
Draws non-interactive overlays on inspected page directly.
When you want to visually annotate DOM elements, for example, for measurements, guides, column, anchors, etc. This has the benefit of almost no context switch since the debugging information is right next to the debugged target.
Complicated layout concepts such as Flexbox and Grid can use overlays to help developers understand these layout intricacies better by showing their alignment, order, and sizing.
Overlays are not interactive yet, and is a bit tricky to implement.
A linkable text or visual element can bring developers to another place when interacted.
Linkability can be added to visual elements when you want to help developers understand the relationship between multiple pieces of information in DevTools, or provide a quick way to jump from a
On hover, linkable texts should show a pointer cursor.
Certain CSS and DOM features that span across different elements or style rules have links between them, such as “popovertarget” attributes in the DOM tree, and CSS variables.
Underlines can be visually distracting when used heavily, and we advise that when there tends to be a lot linkable elements, you only show the underline on hover. A canonical example is CSS variable linking in the Styles tab.
Visual hints signify to users that something is not in its default state with some visual hints, such as greyed-out texts, yellow warning icons, or crossed-out texts. They do not necessarily mean something is not correct: think about the text style for comments in IDEs.
You can use them when you want to help developers realize something is not in the default state, and optionally guide them how to fix it. Some states are called “default” for a reason: you write color: red
and will expect your element’s text to turn red. If it does not turn red, it is in a non-default state. Anything that is acting abnormal is something we should flag to the users with visual hints so that they know what went wrong more easily.
Currently, these visual hints for non-default states usually exist in the Elements panel and the Sources panel, where developers often iteratively modify their page's code to debug.
We show pale texts for:
We show italic texts for style texts that cannot be edited. For example, UA stylesheets cannot be edited, and they are shown in italic texts.
The Styles tab's public documentation contains illustrative examples of how visual hints are used here.
Visual hints, when used heavily, will create visual noises and become less effective for warning people. Please consider how common the non-default state is before using visual hints on them.