DevTools/Features/RichInfobar
Status
| 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. |
Team
| 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
`
Non-goals
`
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
`
Accessibility
`
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 | ` | ` |
