Closed
Bug 1148355
Opened 10 years ago
Closed 6 years ago
Gray menu items in about:newtab menus look disabled
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: phlsa, Unassigned)
Details
Attachments
(1 file)
|
161.76 KB,
image/png
|
Details |
Both the current implementation and the proposed next iteration of menus on about:newtab use gray text for items that are not currently selected.
Gray or dimmed items are usually associated with being disabled, and therefore not selectable. All the native menus on Windows/Mac/Linux and also lots of web and mobile UIs follow that convention, so we should do it too.
The easy answer would be to make all items black (or a very dark gray, both would work IMO), but perhaps Aaron has a different solution here.
| Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(athornburgh)
According to the Chameleon docs I've been working with, the states are even more subtle than that...
The styles specified are black for the active menu item and gray for unselected items. Rolling over another menu item displays a gray checkmark.
I deviated only slightly, choosing to display selected menu items in BOLD and black. On rollover, gray text becomes black, the background becomes white, and a gray checkmark appears - this was done to aid reading and emphasize intractability.
So, if we move towards all black menu items, then I strongly suggest we explore all-new rollover states to indicate hover and active states to make everything super clear. This may have implications throughout Firefox.
If it helps, nobody in user testing mentioned that it was difficult to read or use the New Tab Controls. To the contrary... most participants felt that everything was easy to understand and use.
Flags: needinfo?(athornburgh)
Comment 2•10 years ago
|
||
There have been previous bugs from colors picked with low contrast, e.g., bug 1048137.
The contrast ratio is currently 3.02 for 919191 foreground to FAFAFA background. To get 4.5 contrast ratio, the text should be at least 737373.
| Reporter | ||
Comment 3•10 years ago
|
||
(In reply to Aaron from comment #1)
> According to the Chameleon docs I've been working with, the states are even
> more subtle than that...
>
> The styles specified are black for the active menu item and gray for
> unselected items. Rolling over another menu item displays a gray checkmark.
>
> I deviated only slightly, choosing to display selected menu items in BOLD
> and black. On rollover, gray text becomes black, the background becomes
> white, and a gray checkmark appears - this was done to aid reading and
> emphasize intractability.
>
> So, if we move towards all black menu items, then I strongly suggest we
> explore all-new rollover states to indicate hover and active states to make
> everything super clear. This may have implications throughout Firefox.
>
> If it helps, nobody in user testing mentioned that it was difficult to read
> or use the New Tab Controls. To the contrary... most participants felt that
> everything was easy to understand and use.
As discussed in person...
The main issue is the affordance that the gray entries create. In all menus in Firefox and natively on major platforms, gray means not clickable. Since the main reason behind making those entries gray (differentiating which item is currently selected) now seems to be solved with the checkmark, I don't think there's a reason to keep that inconsistency.
As for the hover state, there are Firefox-native and system-native styles for that. Deviating from them should happen for a reason.
Comment 4•10 years ago
|
||
Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl
Version: Firefox 38 → 38 Branch
Comment 5•6 years ago
|
||
Hello!
This bug has been closed due to inactivity and/or the potential for this bug to no longer be an issue with the new Discovery Stream-powered New Tab experience.
Please help us triage by reopening if this issue still persists and should be addressed.
Thanks!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•