Hi all, Currently in Gecko, we resolve system fonts at compute-time (in nsRuleNode). It adds much complexity to how we handle many things, including * an extra internal property -x-system-font for cascading, * a non-standard keyword value for subproperties of font shorthand, * an extra parameter in SetValue just for system font value, * much special logic in serialization
This complexity shows up when we need to implement the support for stylo in bug 1349417 [1]. It makes me wonder, how does the spec and other browsers handle this complicated stuff? So I checked the spec, and it doesn't explicitly mention whether the resolution happens in parse time or compute time, but it seems to me that its example [2] indicates this should happen in parse time. Then I checked other browsers, and it seems to me both Chrome and Edge do resolve system font at parse time [3], so they are unlikely have that many complexity as us. Per jfkthame, the basic idea of resolving system fonts in compute-time is that we may want to resolve it to different fonts based on the language [4]. However, in practice, it never happens. LookAndFeel::GetFont, the function we call to resolve system fonts, doesn't take a language as a parameter at all [5]. The only thing that may depend on current language is, when we fail to resolve the system font, we fallback to the default font, which is language-dependent. So I then checked the implementation of GetFont, and it seems on macOS, Linux, and Android, this function simply never returns false. On Windows, it may return false when some system call fails [6], but they are not related to specific system font, so I suspect whether that really happens in practice. I propose that, we make system font resolved at parse time via calling LookAndFeel::GetFont from the parser, and if that returns false (which, I think, is unlikely to happen), we fallback to the default font of the UI language. This way, we should remove most of the complexity on system font. And given other browsers are already doing so, I think the compatibility risk should be low. What do you think? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1349417 [2] https://drafts.csswg.org/css-fonts-4/#example-6b1d142f [3] with this test code: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4985 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1349417#c45 [5] https://dxr.mozilla.org/mozilla-central/rev/9577ddeaafd85554c2a855f385a87472a089d5c0/layout/style/nsRuleNode.cpp#3613 [6] for example, https://dxr.mozilla.org/mozilla-central/rev/9577ddeaafd85554c2a855f385a87472a089d5c0/widget/windows/nsLookAndFeel.cpp#543-545 - Xidorn _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
