From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Rich Infobar
Stage On hold
Status `
Release target `
Health OK
Status note Shifting gears. Breaking this into two separate features with different priorities and moving the UX design piece off to the near future.


Product manager Kevin Dangoor
Directly Responsible Individual Kevin Dangoor
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead Stephen Horlander
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks


Stage 1: Definition

1. Feature overview

The "Infobar" is part of the Page Inspector and appears around the highlighted element on the page. The first iteration of the Infobar provided the tag name, ID and classes for the element. This improvement to the Infobar adds features to allow the user to make common changes to the element quickly.

The most important part of this feature is the ability to set pseudo-classes for use in inspecting styles. For example, CSS styles that are applied on "hover" will naturally go away when you switch to the Page Inspector, because you're no longer hovering over the page element you're trying to examine. This feature adds to the infobar a mechanism for making "hover" and other pseudo-classes sticky while you're using the tools.

Toggling classes and setting IDs on page elements are also useful styling features that fit naturally into the infobar.

2. Users & use cases

Anyone doing web design uses this feature.

Examine Hover Styles

It's common to set styles that appear only on hover, so the user needs a way to dig into those styles, see how they're being applied and possibly tweak them using the editing capabilities of other parts of the tools suite.

See the effect of a class

When tracking down styling issues, especially on elements with multiple classes applied to them, it can be useful to visually see the effect that a given class is having on an element. A convenient mechanism for toggling a class on an element is a good way to accomplish this.

Set an ID on an element

JavaScript developers often have collections of functions built up that are designed to take elements or element IDs. By being able to quickly set an ID on an element, these developers will have a handle they can pass into their functions.

3. Dependencies


4. Requirements




Stage 2: Design

5. Functional specification

Selected in the Page Inspector

Pseudo-classes can be toggled in the page inspector so that they can apply to any element-oriented tool (F1).

The user can toggle any of these four common pseudo-classes (F2):

  • active
  • focus
  • hover
  • visited

Those are the four pseudo-classes supported by the most popular developer tools. There are other pseudo-classes that we should try to support as well (F6):

  • link
  • enabled
  • disabled
  • valid
  • invalid
  • checked

Many of these can be set in a "sticky" way by the user in the UI of their application. However, it would be more convenient as they're reviewing the styling for an element if they can just "pretend" to have checked the checkbox, for example.

The tag name (F9) and ID (F10) can be edited.

A command line command can also toggle pseudo-classes on the selected element (F3). There should also be command line commands for toggling classes (F7) and setting the ID (F8).

One open question to acknowledge: when there's a separate tools window we may need a separate UI for doing this same thing from within the tools window.

Pseudo-Class Lifetime

Pseudo-classes stay set until the page inspector is closed (F4). All pseudo-classes are reset to their original values when the tools are closed. This will also require some thought for the interaction with a separate tools window.

Lifetime of Other Changes

Toggled classes and changed/added IDs remain in place after the tools are closed (F9).

Support in Other Tools

The Style Inspector and Rules View will display the proper styles based on the pseudo-classes applied to the element (F5).

6. User experience design

Stephen Horlander offered the suggestion of putting a + at the end of the highlighter Infobar, and Paul Rouget had the suggestions of the click behavior on existing Infobar elements.

  • double-clicking the tag name or ID switches the label to a text box for editing.
  • classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.
  • Clicking the + displays a text field with placeholder text along the lines of :pseudo, #id, or .class.
  • If the user types :, it would the field would contain ":active, focus, hover, visited, ..." with all of the text but the ":" selected.
  • ":a", ":h", etc. should autocomplete to the supported pseudo-classes
  • if the user starts the field with anything but "#", "." or ":" the field should turn red (or otherwise show the error state)
  • if the user types "#" and the node has an ID, the existing ID should be placed in the field, preselected with the cursor after the #

Stage 3: Planning

7. Implementation plan


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

Priority `
Rank 999
Theme / Goal `
Roadmap Developer Tools
Secondary roadmap `
Feature list Desktop
Project `
Engineering team DevTools

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `