[css-fonts-4] system-ui generic font keyword and lang attribute

[drott]

Spun off from:
web-platform-tests/interop#499

This WPT query:
https://wpt.fyi/results/css/css-fonts?label=experimental&label=master&aligned&q=system

has tests
system-ui-ja-vs-zh.html
system-ui-ja.html
system-ui-ur-vs-ar.html
system-ui-zh.html

which are testing whether there's a difference for the system-ui font under differing lang attribute values.

We don't see where that behavior is taken from in terms of spec text.

The spec text itself is: https://www.w3.org/TR/css-fonts-4/#system-ui-def

This generic font family lets text render with the default user interface font on the platform on which the UA is running. A cross-platform UA should use different fonts on its different supported platforms. The purpose of system-ui is to allow web content to integrate with the look and feel of the native OS.

Specifically

default user interface font on the platform on which the UA

reads to us more like it would belong to the locale / language setting of the OS, not specifically the content lang attribute.

CC @kojiishi

[kojiishi]

These tests are added in this CL:
web-platform-tests/wpt@4f31279
@jfkthame @emilio

[jfkthame]

Probably worth checking with some Apple folk about this, as (by my understanding) Safari has been the primary driver of the "ui"-related generics.

Local testing confirms that it definitely uses the content language to resolve system-ui, so that:

data:text/html;charset=utf-8,<div lang=ur style="font:100px system-ui">سلام

renders with a very different font from:

data:text/html;charset=utf-8,<div lang=ar style="font:100px system-ui">سلام

Which is what I'd expect: system-ui in Urdu content yields the font that would be used to present the UI in Urdu, while using it in Arabic content yields the font that would be used to present UI in Arabic. I don't really see how it would be useful to apply a "system UI" font that is not appropriate to the language of the content....

(Currently Firefox renders these two examples identically, but I consider that to be a bug.)

Not sure if @litherum is still around to comment? Maybe @hober / @nt1m / @fantasai can shed further light?

[drott]

I don't really see how it would be useful to apply a "system UI" font that is not appropriate to the language of the content....

I tend to agree with you on that. If we all agree on that, I would prefer to see that clarified in the spec, as I interpret the current wording to either not specify that or even lean in the direction of a default font that the system, not the content lang determines.

[jfkthame]

There's a passing remark in the spec (in Example 6) about:

how system-ui is expanded to include a collection of system user interface fonts

which I think relates to the idea that there may not be a single "UI font" that covers everything, so "the UI font" may in fact be multiple fonts, with language support being the obvious basis on which they'd be organized. But then the question arises as to how to choose which font from the "collection of system user interface fonts" to use for any given piece of content, if there's any overlap whatsover in their coverage.

And that, I guess, is where the content lang comes into play, implicitly... e.g. the collection might include both a Naskh Arabic font and a Nastaliq font, both covering the Arabic character repertoire, and lang=ar vs lang=ur guides the choice of which to use.

But that's all somewhat vague, and could certainly use clarification.

[svgeesus]

I'm hearing rough consensus that the spec should clarify the use of the content language, perhaps with an Urdu example as well.

[kojiishi]

"The default user interface font on the platform on which the UA is running" is not in the content-language, but in the platform language, no?

Aside that, I wonder if it's implementable on other platforms without having a full list of fonts for all languages on the platform. Anyone knows?

[jfkthame]

"The default user interface font on the platform..."

But in practice "the default user interface font" is not a single font; as the note in Example 6 suggests, it is really a collection of fonts -- otherwise not all languages would be able to be displayed in the UI.

If my platform language is (say) Hindi, and the default UI font being used for the Hindi interface is Nirmala UI, but then the UI needs to display some text in Russian or Hebrew or Chinese, the platform is going to have to use a different font for that part of the UI. So what "the UI font" actually resolves to will depend on the content it's being asked to display.

Primarily, the supported character repertoire of the various font resources will determine which UI font can be used for a given piece of text, but in some cases (e.g. Chinese vs Japanese, or Arabic vs Urdu) language may also be important. And that should clearly (IMO) be the language of the content concerned, if known.

[kojiishi]

But in practice "the default user interface font" is not a single font; as the note in Example 6 suggests, it is really a collection of fonts -- otherwise not all languages would be able to be displayed in the UI.

Right, most modern OS have the mechanism to link or fallback multiple physical fonts. We agree on this point, right?

As you know, the "font set" (or "font fallback list" or "font link set") usually vary by the platform UI langauge. IIRC, macOS stores a list of fonts in a plist, that can have if-branch by the language, if my knowledge isn't outdated.

For this issue, I think the question is whether the "font set" emulation in the browser should be the "font set" of the platform language, or of the content language.

I think the original motivation was to expose the "font set" mechanism, in order for web apps to have the same look-and-feel with other native apps. From that perspective, I assumed that it's platform language, because all other apps are in the platform language.

If we want to change that, or if it was my misunderstanding, I'm fine, but as far as I know, it's technically not possible on Windows at least. I'm not very familiar with Linux. If we were changing this, I wish us to make sure it's implementable on all platforms.

[kojiishi]

Just to make sure we're on the same page, we're talking about system-ui, not ui-*, right? The latter is "good font that has no latency," so I can agree with the content-language. We'll need to create a curated list when we support it anyway. The former is "match other native apps, even if the system font doesn't look good" as far as I understand.

[litherum]

(Disclaimer: I don't work on web tech any more; I'm just commenting to provide background info.)

I think we're discussing a few different things here:

1. The purpose of system-ui is supposed to be "make this text look like it was drawn by the native ui text-drawing routines." On macOS/iOS, those native ui text-drawing routines behave as-if they expand the single font to become a whole cascade list - so that's what WebKit's implementation does too. Ideally, all browsers on those operating systems would behave accordingly; though I can't comment on their behavior.
2. That's a different thing than what the OP is describing - the OP is asking whether that expansion operation should be affected by locale or not. Following from the goal of "make this text look like it was drawn by the native ui text-drawing routines," that expansion operation is affected by locale on macOS/iOS, so system-ui should behave that way in browsers too on those OSes.
3. That locale should definitely be able to be specified by the web author via lang=. If they don't specify it, I'm not sure what the best behavior should be. I see an argument of "using the OS's locale is going to be the option that most likely produces text that's best for the user" but I also see an argument of "different users shouldn't see different fonts for the same content in the same browser on the same OS." I think there is an analogous situation here with hyphenation, but the failure case is different: picking a different font makes the text look weird but still legible, whereas picking different hyphenation locations makes the text not really legible any more.
4. Anyway, back to the OP: I think it's good to have tests to make sure that the expansion is locale-dependent to match OS behavior: it's easy to make real bugs here, and this is a situation where if a browser doesn't do it, the browser is clearly and visibly wrong on those OSes. However, I don't know how to fit that into the WPT infrastructure - is it possible to make an OS-specific test?

[svgeesus]

@jfkthame wrote:

"the default user interface font" is not a single font; as the note in Example 6 suggests, it is really a collection of fonts

There is more text (and crucially, not just in an example) (my emphasis):

Each keyword represents a generic font choice, and behaves as a potential alias for one or more locally-installed fonts belonging to the specified generic font category

and also

A generic font family is a font family which has a standard name (as defined by CSS), but which is an alias for an existing installed font family present on the system. However, a single generic font family may be a composite face combining different typefaces based on such things as the Unicode range of the character, the content language of the containing element, user preferences, system settings, etc.

So it seems well established that generics can map to multiple local fonts and that content language can be used to choose among them. It is just a case of clarifying in system-ui so that the apparent prohibition is no longer present.

[svgeesus]

I added

(which, as with all [[#generic-font-families]] may be a composite font)

and

The precise font used will depend on factors such as
Unicode coverage
and the content language.

@jfkthame @drott @kojiishi does that cover it, or is more clarification needed?

[svgeesus]

Ping @jfkthame @drott @kojiishi does that cover it, or is more clarification needed? Ok to close?