Here's the current state of all browsers and platforms, tested only in English:
* Firefox and Chrome on all platforms use `font-family: monospace` for `<input type=date>`, whereas Safari uses `font-family: system-ui` (notably not `system-ui-monospace`, which would yield SF Mono)
* The `monospace` generic currently maps to
* Courier on all macOS browsers
* "monospace" (which fontconfig maps to DejaVu Sans Mono on my system) in Firefox and Chrome on Linux
* Courier New in Firefox and Consolas in Chrome on Windows
We don't currently have a way to use SF Mono from CSS, since it's a hidden font. In theory the right way to expose that is through the `system-ui-monospace` generic, which we don't implement yet. (And I guess it's possible a macOS maps requests for the "system UI monospace font" to something other than SF Mono for other languages.)
I think the most important thing is to update Windows from using Courier (which is exceptionally thin!) to something else. Consolas seems good for consistency with Chrome.
On macOS I lean towards sticking with Courier for the monospace font, again for consistency with other browsers. (And it's not nearly as ugly as Courier New.) Menlo is also ~17% taller than Courier. We could also consider using Menlo on `<input type=date>` specifically, and leaving monospace to map to Courier.
Another thing I discovered a few weeks ago is that many language-specific font prefs for the monospace generic do not specify a monospace font. As a result, documents like
```
<!DOCTYPE html>
<html lang=ko>
<pre>if (x > 10) {
...
}</pre>
```
at least on macOS, show the `pre` with a proportional font. So we might want to take the opportunity to fix these up at the same time.
Bug 1607913 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Here's the current state of all browsers and platforms, tested only in English:
* Firefox and Chrome on all platforms use `font-family: monospace` for `<input type=date>`, whereas Safari uses `font-family: system-ui` (notably not `system-ui-monospace`, which would yield SF Mono)
* The `monospace` generic currently maps to
* Courier on all macOS browsers
* "monospace" (which fontconfig maps to DejaVu Sans Mono on my system) in Firefox and Chrome on Linux
* Courier New in Firefox and Consolas in Chrome on Windows
We don't currently have a way to use SF Mono from CSS, since it's a hidden font. In theory the right way to expose that is through the `system-ui-monospace` generic, which we don't implement yet. (And I guess it's possible a macOS maps requests for the "system UI monospace font" to something other than SF Mono for other languages.)
I think the most important thing is to update Windows from using Courier New (which is exceptionally thin!) to something else. Consolas seems good for consistency with Chrome.
On macOS I lean towards sticking with Courier for the monospace font, again for consistency with other browsers. (And it's not nearly as ugly as Courier New.) Menlo is also ~17% taller than Courier. We could also consider using Menlo on `<input type=date>` specifically, and leaving monospace to map to Courier.
Another thing I discovered a few weeks ago is that many language-specific font prefs for the monospace generic do not specify a monospace font. As a result, documents like
```
<!DOCTYPE html>
<html lang=ko>
<pre>if (x > 10) {
...
}</pre>
```
at least on macOS, show the `pre` with a proportional font. So we might want to take the opportunity to fix these up at the same time.