Bug 215121 – monospace font inconsistently selected

• Status: ASSIGNED
• Component: Text

[Sam Sneddon [:gsnedders]]

Since wpt.fyi first started trying to run Catalina(!) and STP 111, there’s a whole bunch of regressions that appear to be down inconsistent font selection (no in-depth analysis done on most, merely noted they visually appear to be the same issue).

An example is:

https://wpt.fyi/results/css/CSS2/bidi-text/bidi-011.xht?diff&filter=ADC&q=seq%28%28status%3Apass%7Cstatus%3Aok%29%20%28status%3A%21pass%26status%3A%21ok%26status%3A%21unknown%29%29&run_id=625120001&run_id=619180001

i.e.,
test: http://wpt.live/css/CSS2/bidi-text/bidi-011.xht
ref: http://wpt.live/css/CSS2/bidi-text/bidi-011-ref.xht

Both of these have `font: 2em monospace`. I _think_ the test is matching Menlo and the ref is matching Courier, but that is from a brief visual inspection.

From a brief glance, it appears some of the failures in bug 214290 are related.

<rdar://66400419> (which hopefully works to link this)

[Radar WebKit Bug Importer]

<rdar://problem/66514901>

[Alexey Proskuryakov]

<rdar://66400419>

[Sam Sneddon [:gsnedders]]

From discussion with Myles:

There was a desire to use the system's monospace font in at least some cases, as Menlo / Monaco have better typography than Courier, while still not being inconsistent with other browsers.

The decision previously was to try and thread the web compat needle by using Courier in the case when no lang was explicitly provided, and use the system default otherwise.

On the whole, my suggestion is to try and see if we can get away with using the lang=en system default for no-lang, rather than using Courier when no lang is provided, as this difference between lang=en and no-lang just introduces another web compat risk (as WPT has found).