New issue
Advanced search Search tips

Issue 794795 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

MacViews: Button label font weight should be NORMAL on all macOS versions

Project Member Reported by tapted@chromium.org, Dec 14 2017

Issue description

Chrome Version       : 64.0.3278.0
OS Version: OS X 10.12.6

Per the thread at https://groups.google.com/a/google.com/d/msg/chrome-harmony/iycfk6mI6U8/OaAClDh5CgAJ

When LCD font smoothing is enabled on Mac (which is the default), the system font renders kinda bold-looking. Particularly when drawing white text on a dark background. To the extent that MEDIUM (the closest we can get to NORMAL) looks too bold.

macOS 10.9 and macOS 10.11 don't ship with a MEDIUM weight system font so are already using NORMAL.

Decision: just make it NORMAL weight everywhere.
 

Comment 1 by tapted@chromium.org, Dec 15 2017

Status: Started (was: Assigned)
CL -> https://chromium-review.googlesource.com/828002

Note regarding contrast for the blue/prominent buttons:

White on kGoogleBlue500 is a contrast ratio of 3.6, which is less than the 4.5 requirement from WCAG (https://www.w3.org/TR/WCAG20-TECHS/G18.html).

 - http://leaverou.github.io/contrast-ratio/#white-on-rgb%2866%2C%20133%2C%20244%29

WCAG defines lower thresholds for bold text, which will no longer apply to this after removing bold.

But solid white on kGoogleBlue500 has an exception granted - see http://go/mdcontrast

Comment 2 by tapted@chromium.org, Dec 20 2017

Cc: bettes@chromium.org
Removing the bold from the non-default buttons seems to have a bigger than expected impact too.
The contrast ratio is only just below the requirement, at 4.4: 
http://leaverou.github.io/contrast-ratio/#rgb%28120%2C%20120%2C%20120%29-on-white

But since the font doesn't occupy many pixels, most of them get a font that is lighter than #787878

Also the result when that LCD font-smoothing checkbox is unchecked is awful.

I don't think we can land that CL.
nobold.png
33.2 KB View Download

Comment 3 by tapted@chromium.org, Dec 20 2017

actually those two screengrabs are with a bold font. (and the one without font smoothing still looks bad)
largefont_bold.png
83.7 KB View Download
nofontsmoothing_boldtext.png
23.4 KB View Download
Cc: tapted@chromium.org
Labels: MacViews-Controls Target-69
Owner: spqc...@chromium.org
MacViews triage: this reproduces for me. Assigning to spqchan@ for M-69 fix.

Comment 5 by tapted@chromium.org, Mar 26 2018

Note I'm not sure what action should be taken here. I think we are still happy with how things are shipping, but might want a mac-specific tweak once things settle down. It might involve detecting the `font smoothing` setting and acting on that as well as (how we do currently) on macOS-version.

Fixing the bug as written will make the button font too scratchy (and low-contrast) for users without font-smoothing enabled.

Comment 6 by gov...@chromium.org, Mar 27 2018

Labels: M-69
Owner: ellyjo...@chromium.org
Status: Assigned (was: Started)
Owner: lgrey@chromium.org
macviews triage: lgrey@, over to you :)

Comment 9 by lgrey@chromium.org, May 30 2018

bettes@ what's your take on c#5?
Labels: -M-69 Group-Visual_Defects
Labels: M-69
Labels: -M-69 -Target-69 M-70 Target-70
bettes: Making it NORMAL for all macOS versions lgtm.
Note that macOS 10.14 Mojave has dropped support for subpixel AA, so the premise that "the system font renders kinda bold-looking" will no longer hold true there. (i.e. since filing this bug, this new info suggests that we may actually want MEDIUM again).

Sign in to add a comment