[css-fonts] Empty quoted font family name should not parse as valid

[drott]

In a recent Chrome issue we discovered that a style definition such as:
font: 1px "";
would parse as valid according to the spec prose.

Similarly, a JS font loading call such as:
document.fonts.load("1px \"\"")
leads to a promise with status resolved / fulfilled in Safari / Firefox, even though to me that does not make sense, as a font with an empty family name cannot be reasonably matched.

I suggest to add normative text in section 3.1 below the following paragraph:

Font family names other than generic families must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names.

similar to

The empty quoted string: "" is an invalid font family name.

Then we can add to the examples:

font-family: "", sans-serif;
font-family: "";

Perhaps we need to add something as well to describe that:
font-family: ,,,;
also should not parse as valid, i.e. a sequence of null identifiers separated by commas.

[drott]

CC @tabatkins @kojiishi @lilles

[lilles]

Why can't we just handle the empty string the same way we handle a non-empty string that does not map to a known font?

I think "font-family: ,,,;" is already covered by the current syntax in the spec? There is no such thing as a null identifier?

[drott]

I find it inefficient to let an empty string "" travel up to font matching if it can be rejected at the parsing stage. Also, fulfilling a promise document.fonts.load("1px \"\"") is hiding a potential bug in a page's JS code if for example a variable for font family wasn't set. In my opinion, resolving this promise successfully is semantically misleading, as no font will have been matched or loaded for the empty family name.

[drott]

CC @jfkthame @litherum

[jfkthame]

I don't see that

 document.fonts.load("1px \"\"")

is any more "misleading" than

 document.fonts.load("1px 'Some random font name that does not actually exist'")

which also resolves to a fulfilled promise. In either case, no actual font loading takes place because the given name doesn't match any available font.

[litherum]

@jfkthame is right.

[svgeesus]

So, discussion on this issue seemed to conclude that a promise returning does not mean the font was successfully loaded; and thus, that no changes are needed. Is that the consensus?