[css-fonts][cssom] Serialization of font properties when system font is specified

[upsuper]

For example, if I have font: menu, what should be returned for

• getPropertyValue('font')
• getPropertyValue('font-family')
• cssText

This isn't quite interop at the moment. See the following table on Windows:

Browser	font	font-family	cssText
Blink	12px "Segoe UI"	"Segoe UI"	expand to all longhands
Edge	menu	Segoe UI	font: 400 9pt Segoe UI;
Gecko	menu	-moz-use-system-font	font: menu;

In Gecko, we use an internal property for holding system font with a placeholder value on all font longhands. And then we expand that to actual value during computation. I admit that the -moz-prefixed thing doesn't make much sense here anyway.

It seems to me that Blink expands the system font into their actual value during parsing. This is probably the simplest way to implement, and the spec somehow indicates this behavior (see the last yellow box in the section of font shorthand), but there is a problem with this approach that, it would be unable to respond to system setting changes.

Edge seems to go a middle path, although I'm not sure how exactly it is implemented. My guess is that, they store system font as specified value, and when others want to serialize the longhands, it returns the effective value of the corresponding system font?

It would probably make most sense to standardize some behavior similar to Edge, but returns font: menu; for cssText instead, I guess.

[litherum]

These values shouldn't turn into the platform-specific font name. This is because on iOS and macOS, the "system font" is actually an entire cascade list of fonts, including Ping Fang for Chinese and our own custom Arabic system font. Therefore, representing a system font as simply the first entry in this fallback list is incorrect, and the keyword menu (in this case) should be returned instead.

[upsuper]

By font-family, I actually want to indicate the general font longhands, like font-size, font-weight, etc. They can all depend on the system. What should them be serialized to? Are they also affected by the cascade list?

[litherum]

It seems to me that font-size, font-weight, etc. can just be chosen to be values which the implementation decides. My previous statement was just about font-family and font.

[upsuper]

It seems in WebKit, menu is parsed into -apple-menu for font-family, which, I guess, behaves like a generic font family. And I suppose -apple-menu is actually a valid value for font-family in WebKit as a generic family. (And it seems Blink uses system-ui generic family in this case.)

It doesn't seem to affect my proposal, I guess?

[upsuper]

My point is that:

• we shouldn't force UA to resolve system fonts at parse time (because they may want to respond to system setting changes), but
• serialization should always return meaningful value as itself.

[tabatkins]

These values shouldn't turn into the platform-specific font name. This is because on iOS and macOS, the "system font" is actually an entire cascade list of fonts, including Ping Fang for Chinese and our own custom Arabic system font. Therefore, representing a system font as simply the first entry in this fallback list is incorrect, and the keyword menu (in this case) should be returned instead.

menu isn't a reserved font-family keyword, so we can't return it as the value for font-family. We need to introduce some specific keywords for handling that, which browsers currently have done with prefixed-keywords.

[tabatkins]

(AKA shorthands aren't allowed to have behavior on their own - they must be fully explained by the longhands they break down into.)

[FremyCompany]

We have a similar problem when variables are involved.

My personal thinking is that we should have a special function to resolve these cases, like this:

font-family: from(font: menu);
border-left-width: from(border: var(--hover-border, 2px solid red));

But I didn't think this through very much.

[dbaron]

In hindsight (and I think I may have said this in one of the stylo discussions about system fonts) I think the mistake I made in the Gecko design I did in bug 377947 in 2007 was having the -internal-system-font property. Instead of expanding font: menu into -internal-system-font: menu; font-family: -moz-use-system-font; font-size: -moz-use-system-font; ... I should have just done font-family: system-font(menu); font-size: system-font(menu); ....

In fact, failing to do so is technically buggy since it doesn't correctly support:

parent { font: menu }
child { font: icon; font-size: inherit }

[upsuper]

parent { font: menu }
child { font: icon; font-size: inherit }

isn't buggy in even the old Gecko engine, because system fonts becomes concrete values during computation anyway, and inherit inherits the concrete computed value rather than specified value.

[css-meeting-bot]

The Working Group just discussed [css-fonts] [cssom] Serialization of font properties when system font is specified, and agreed to the following resolutions:

• RESOLVED: serialization when system fonts are used to font properties to L4 of Fonts

The full IRC log of that discussion

<dael> Topic: [css-fonts] [cssom] Serialization of font properties when system font is specified
<dael> github: https://github.com//issues/1586
<dael> Chris: myles points out on iOS and macOS the system font is a cascade of fonts. What do you serialize out.
<dael> Rossen_: I would love if serialization for this is a new proposed constant/static variable proposed by dino so people can take it and use it and not worry about the actual font.
<dael> Rossen_: Coming back and saying here's your variable would be awesome. I don't know what that means for compat, but it's awesome.
<dael> Chris: mmm.
<dael> astearns: Since we don't have compat on this and the prop on the table is to depend on something still being spec perhaps this goes to fonts 4?
<dael> Chris: Fonts 4 is reasonable, but what text changes in fonts 3 if we do that. Where is the text that says do a thing. Oh, in setting font shorthand section.
<dael> Rossen_: If we have an agreement to move to L4 you can work out editorial details later.
<dael> Chris: Indeed.
<dael> Chris: Also effects CSSOM
<dael> dbaron: One problem here is there's a bunch of behavior with no spec result in CSS and impl have to make it up.
<dael> Chris: Yes.
<dael> astearns: I'm interested in getting this spec, but I'm also interested in getting fonts 3 forward. Since we don't have interop and it may take a while to settle on this I think I'm happier doing it in fonts 4
<dael> astearns: So dbaron we do need it spec, but maybe not this level
<dael> dbaron: Fine.
<dael> astearns: Obj to moving serialization to font properties to L4 of Fonts?
<dael> dbaron: Serialization of them when system fonts are used.
<dael> astearns: Yes.
<dael> Chris: Fonts 3 can say it's unspec?
<dael> astearns: I think it should say we intend to spec in next level.
<dael> RESOLVED: serialization when system fonts are used to font properties to L4 of Fonts