For Firefox 128, I intend to add CSS support for `-webkit-font-smoothing: antialiased`. This will be aliased to the existing `-moz-osx-font-smoothing: grayscale` property, and therefore under the control of the same pref, and relevant only on macOS. See below for additional background. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1670993 Standard: None Platform coverage: macOS Preference: layout.css.osx-font-smoothing.enabled DevTools bug: n/a Link to standards-position discussion: None Other browsers: * WebKit: shipping * Blink: shipping web-platform-tests: None (non-standard property) JK - - - - - Background discussion: The non-standard CSS property -webkit-font-smoothing was originally introduced by Safari (I believe), and allows authors to choose between subpixel antialiasing (when supported by the content in question; sometimes it is unavailable for other reasons) and grayscale-only antialiasing. The antialiasing mode can sometimes make a quite noticeable difference to the apparent "weight" and clarity of font rendering. This applies especially to light-on-dark text on macOS, where the system's native font rasterizer tends to "thicken" glyph shapes significantly. Authors often use the property `-webkit-font-smoothing: antialiased` on such content to get glyph rendering that is more consistent with dark-on-light text, and with other platforms. The lack of any specification for -webkit-font-smoothing[1], its rather confusing values, and the fact that it only affects macOS, led us to implement a similar feature (in bug 857142) under the name -moz-osx-font-smoothing (with differently-named values that we felt were clearer). Authors can therefore get consistent results by specifying: -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; for relevant content. However, we continue to see a significant amount of content that specifies only the -webkit- version of the property, and doesn't include the -moz- one. This degrades the rendering that macOS users see, and looks to them like a Firefox bug. While the lack of any engagement with the spec question is regrettable (and maybe we can push to get it improved), our users will be best served by going ahead with what is proposed in bug 1670993: aliasing the -webkit- version of the property to our -moz- implementation. [1] See https://github.com/whatwg/compat/issues/115; Mike asked for some kind of spec five years ago, but nobody seems to have noticed.
On 5/31/24 4:08 AM, Jonathan Kew wrote:
[1] See https://github.com/whatwg/compat/issues/115; Mike asked for some kind of spec five years ago, but nobody seems to have noticed.