Browser tabs do not follow the correct HCM styles
Categories
(Firefox :: Theme, defect, P3)
Tracking
()
People
(Reporter: nstroud, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
126.58 KB,
image/png
|
Details |
Prerequisites:
Found in Nightly 136.0a1 (2025-01-07)
Turn on Night Sky HCM in Windows
STR:
- Follow prerequisites above
- Open Firefox Nightly
Expected / Actual:
The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.
Reporter | ||
Updated•1 month ago
|
Comment 1•1 month ago
|
||
(In reply to Natalie Stroud [:nstroud] from comment #0)
The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.
So this is the first time I see this, or at least the first time I'm noticing that the above mockup reverses the active tab and tabs toolbar colors. I'm not sure I understand the a11y benefits of this, and it seems to break the intended visual hierarchy of the UI where the active tab is supposed to pick up the navigation toolbar colors. Do you have additional context for the mockup and why it breaks with our established design?
Comment 2•1 month ago
•
|
||
(In reply to Dão Gottwald [:dao] from comment #1)
(In reply to Natalie Stroud [:nstroud] from comment #0)
The Desktop Anatomy, specifically the browser tabs, should follow the HCM styling found in the High Contrast Mode file in Figma. At this time, the styling does not match in Nightly.
So this is the first time I see this, or at least the first time I'm noticing that the above mockup reverses the active tab and tabs toolbar colors.
The mockup uses SelectedItem
for the background, not the toolbar colour (which I believe is something like mozHeaderBar or WindowBackground?). SelectedItem
better represents (semantically) the active tab's state within the tab list of all tabs.
I'm not sure I understand the a11y benefits of this, and it seems to break the intended visual hierarchy of the UI where the active tab is supposed to pick up the navigation toolbar colors. Do you have additional context for the mockup and why it breaks with our established design?
Because each tab is a clickable control, they inherit our HCM, non-primary control styling. This means they use ButtonFace
background and ButtonText
foreground/border styling. They also inherit our selectable control styling, where the currently selected control gets SelectedItem
and SelectedItemText
colours, but keeps its ButtonFace
border to indicate interaction is possible.
In general, our HCM designs will differ from the visual language presented in our non-HCM ones, since the goal of HCM is to provide semantic colouring which indicates state and actions available, however the visual language within our HCM components should be consistent. The Desktop Anatomy that nstroud linked has been workshopped with the design systems team, who have audited the design for consistency with the existing HCM library.
Updated•26 days ago
|
Description
•