Steps to reproduce the problem: 1. Load testcase at https://codepen.io/jfkthame/pen/dyKgwPv 2. Observe rendering of line "Test 1". The example uses a @font-face rule with `src: local(system-ui)`. However, "system-ui" is not the name of an available font face on the system; it's a generic CSS font *family* (not *face*) name. Therefore, the `local(system-ui)` source should be ignored and the next listed source used instead. Safari displays the "Test 1" line using the system UI font family (".SFNS"). Some quotes from the relevant spec text at https://drafts.csswg.org/css-fonts-3/#font-face-name-value: > The locally-installed <font-face-name> argument to local() is a format-specific string that uniquely identifies a single font face within a larger family. > For OpenType and TrueType fonts, this string is used to match only the Postscript name or the full font name in the name table of locally available fonts. The CSS generic family names clearly don't fit this at all, and therefore they should not "work" in `src:local(...)`.
<rdar://problem/103176955>
Here's a problem: How would someone specify the system San Francisco font in a @font-face rule, if not with system-ui? I know a lot of Apple users use a custom style, either in a user style sheet or a browser extension, to replace page fonts with the default system font.
> Here's a problem: How would someone specify the system San Francisco font in a @font-face rule, if not with system-ui? > I know a lot of Apple users use a custom style, either in a user style sheet or a browser extension, to replace page fonts with the default system font. This doesn't require a @font-face rule, does it? Just do `font-family: system-ui` as a CSS property.
(In reply to Jonathan Kew from comment #3) > > Here's a problem: How would someone specify the system San Francisco font in a @font-face rule, if not with system-ui? > > > I know a lot of Apple users use a custom style, either in a user style sheet or a browser extension, to replace page fonts with the default system font. > > This doesn't require a @font-face rule, does it? Just do `font-family: > system-ui` as a CSS property. I'm talking about global replacement of one font with another everywhere on every web page. @font-face rules were made for that. CSS properties need CSS selectors. Also, CSS selectors are generally not great at selecting based on other CSS properties, which can come from different places, such as style sheets.
If anything, what ought to work in src:local would be the font's PostScript name, so: @font-face { font-family: test; src: local(".SFNS-Regular"); } That doesn't currently appear to work, at least in the version of Safari I have on hand; but in principle it would be a valid thing to do, if Apple didn't choose to hide .-prefixed fonts. If you think such fonts should be exposed to @font-face, that'd be something to consider in a separate bug.
(In reply to Jonathan Kew from comment #5) > If anything, what ought to work in src:local would be the font's PostScript > name, so: > > @font-face { font-family: test; src: local(".SFNS-Regular"); } > > That doesn't currently appear to work, at least in the version of Safari I > have on hand; but in principle it would be a valid thing to do, if Apple > didn't choose to hide .-prefixed fonts. > > If you think such fonts should be exposed to @font-face, that'd be something > to consider in a separate bug. I'd be happy to file another bug if necessary. However, I don't think this bug should be "fixed" until there's a replacement. Especially because it would mean taking away useful functionality, for no apparently advantage. Perhaps the spec itself should be rethought? Is there a reason that local() is so restrictive and doesn't accept generic font names?
This bug should be fixed because it breaks interoperability with standard-compliant browsers. local() doesn't accept "generic font names" because _they are not "font names"_, they represent (potentially composite and/or language/locale-dependent) "font family names", which is a different thing. As the spec says, > The locally-installed <font-face-name> argument to local() is a format-specific string that uniquely identifies a single font face within a larger family. That is not what system-ui does.
(In reply to Jonathan Kew from comment #7) > This bug should be fixed because it breaks interoperability with > standard-compliant browsers. Does it break interoperability? As far as I can tell, there doesn't seem to be any actual harm from allowing system-ui to work in local(). In fact, the source of this WebKit bug is a Mozilla bug where the bug reporter expected system-ui to work rather than expecting it to fail: https://bugzilla.mozilla.org/show_bug.cgi?id=1801687 I would contend that everyone in the world who writes local(system-ui) in CSS expects and hopes for it to work. (Except for someone writing a bug against the spec, for the sole purpose of spec conformance.) To me, allowing system-ui feels like a "victimless crime" against the spec. This bug isn't requesting a feature to work in Webkit that doesn't currently work; rather, it's requesting a feature to stop working that does currently work in WebKit. A feature that currently benefits some users. I don't see how breaking this feature — especially without any replacement in place — helps browser interoperability or helps WebKit users. > local() doesn't accept "generic font names" because _they are not "font > names"_, they represent (potentially composite and/or > language/locale-dependent) "font family names", which is a different thing. > > As the spec says, > > > The locally-installed <font-face-name> argument to local() is a format-specific string that uniquely identifies a single font face within a larger family. > > That is not what system-ui does. When I asked "Is there a reason that local() is so restrictive and doesn't accept generic font names?" I wasn't asking for a definition of the spec, I was asking for a practical justification for the spec.
> I would contend that everyone in the world who writes local(system-ui) in CSS expects and hopes for it to work. (Except for someone writing a bug against the spec, for the sole purpose of spec conformance.) To me, allowing system-ui feels like a "victimless crime" against the spec. I would suggest that it's a "crime" against the Safari users who write such CSS and assume that it'll render in a certain way, because of how it looks in their browser; but then when their content is viewed by a Firefox or Chrome user, it looks bad/broken. Or from another point of view, it's a "crime" against the Firefox and Chrome users, because it leads to Safari-using authors creating content that doesn't work well in those browsers. That's exactly what an interoperability problem looks like, and it's happening because webkit does not follow the (very long-standing) requirements of the CSS specification here. If the webkit bug here is fixed so as to conform to the specification, any Safari-using authors who want their page to use the macOS system font will be nudged to use the system-ui keyword in the manner the spec intends (as a value in the font-family list) and it'll work consistently across all the browsers.
(In reply to Jonathan Kew from comment #9) > If the webkit bug here is fixed so as to conform to the specification, any > Safari-using authors who want their page to use the macOS system font will > be nudged to use the system-ui keyword in the manner the spec intends (as a > value in the font-family list) and it'll work consistently across all the > browsers. This misses an important use case, which I mentioned earlier: "I know a lot of Apple users use a custom style, either in a user style sheet or a browser extension, to replace page fonts with the default system font." It's not just about page authors. It's not just a Safari/Apple issue either. In general, CSS writers are confused about why @font-face behaves differently and has different rules than the CSS font property. We use generics in font-family so why not @font-face? Is there a good reason why we can't use local(sans-serif) for example? I don't see why it ought to be restricted from using generics, regardless of browser or platform. system-ui is a prominent example, because Apple has a vendor-specific system font, but the question of why local() can't use generics is broader. I suspect that more CSS authors would use it if it were possible.