[css-font-loading] Lack of interop on FontFace constructor.

[emilio]

new FontFace("Font 01", "").family

Is an empty string in Gecko, because Font 01 is not a valid family name (you need to quote it because 01 is not a CSS identifier)

Safari says normal.

Chrome says Font 01.

My understanding is that Gecko is right, per https://drafts.csswg.org/css-font-loading/#font-face-constructor:

Parse the family argument, and the members of the descriptors argument, according to the grammars of the corresponding descriptors of the CSS @font-face rule. If the source argument is a CSSOMString, parse it according to the grammar of the CSS src descriptor of the @font-face rule. If any of them fail to parse correctly, reject font face’s [[FontStatusPromise]] with a DOMException named "SyntaxError", set font face’s corresponding attributes to the empty string, and set font face’s status attribute to "error". Otherwise, set font face’s corresponding attributes to the serialization of the parsed values.

But given the lack of interop other members may disagree? What is exactly going on in Safari / Chrome?

@litherum @lilles

[jfkthame]

FWIW, Safari seems to say normal no matter what is passed as the first argument - even if it is a valid family name:

› new FontFace("FamilyName", "").family
‹ "normal"

Chrome, on the other hand, accepts whatever string it is given, whether or not it would be a valid family name:

› new FontFace("@;! /* foo */", "").family
‹ "@;! /* foo */"

It seems to be treating the value of the string as though it were additionally quoted?

[GitHubStig]

Safari seems to require the 2nd parameter to use the url() syntax:

› new FontFace("FamilyName", "url()").family
‹ "FamilyName"

› new FontFace("@;! /* foo */", "url()").family
‹ "@;! /* foo */"

[lilles]

I agree this is a Chrome bug

[jfkthame]

It's also a Safari bug, right? Setting aside the question of the 2nd parameter, it's wrong to accept "@;! /* foo */" (where the quotes are just the JS quotes around the string, not part of the value) for the family name.

It'd need to be "'@;! /* foo */'" or similar to be a valid (though weird) font-family name.

[shivamidow]

Regarding the rule for parsing family names in FontFace(), do we have the relevant specification document? I believe it's based on https://drafts.csswg.org/css-fonts/#family-name-syntax, correct?

It'd need to be "'@;! /* foo */'" or similar to be a valid (though weird) font-family name.

I have a related question—how is the family name stringified? Specifically, are single and double quotes treated differently? Should they be retained? I've observed that Gecko, Blink, and WebKit each handle the following example differently.

const fontface1 = new FontFace("'123'", 'url()');
console.log('1. fontface.family:', fontface1.family);

const fontface2 = new FontFace('"123"', 'url()');
console.log('2. fontface.family:', fontface2.family);

const fontface3 = new FontFace('123', 'url()');
console.log('3. fontface.family:', fontface3.family);

const fontface4 = new FontFace("123", 'url()');
console.log('4. fontface.family:', fontface4.family);

My original thought was simply 123 returned without quotes, but the results vary.

Blink output: the outer quotes peel off, but the inner quotes are retained as they are.

1. fontface.family: '123'
2. fontface.family: "123"
3. fontface.family: 123
4. fontface.family: 123

Gecko output: The inner single quotes are replaced with double quotes. Although the original font name is 123, but "123" (a quoted name) is returned.

1. fontface.family: "123"
2. fontface.family: "123"
3. fontface.family: <empty string>
4. fontface.family: <empty string>

WebKit output: The outer quotes peel off. But, the name seems to be (double) quoted again when it is stringified.

1. fontface.family:"'123'"
2. fontface.family:"\"123\""
3. fontface.family:"123"
4. fontface.family:"123"

[svgeesus]

I have a related question—how is the family name stringified?

From 13.2. Serializing font-related at-rules

Unless specifically noted for individual descriptors, the descriptors defined for at-rules in this module follow the principles of CSSOM § 6.7.2 Serializing CSS Values.)

and 4.2. Font family: the font-family descriptor has no specific overrides on that.

Specifically, are single and double quotes treated differently?

[CSSOM § 6.7.2 is silent on that, apart from "Please consult that property’s specification and/or your local reverse-engineer for details"

[emilio]

We've found other sites broken by this. For now I plan to quote invalid CSS family names rather than rejecting the font load. Would be good to converge on that: https://bugzilla.mozilla.org/show_bug.cgi?id=1986533