Update font-family support and font shorthand support

[asamuzaK]

Fix #212
Also fixes jsdom/jsdom#3021
And can close #121

Regression test for jsdom jsdom/jsdom#3889

[domenic]

Thanks for your quick work here! However now I am wondering if the spec or tests also need updates...

https://wpt.fyi/results/css/cssom/font-family-serialization-001.html?label=experimental&label=master&aligned is interesting in particular.

[asamuzaK]

Re: https://wpt.fyi/results/css/cssom/font-family-serialization-001.html
I don't think this is a good test, but I don't have any suggestions for a fix.
And I don't know about the history of spec changes, but the file on which the tests are based appears to have been last updated four years ago.
See https://github.com/web-platform-tests/wpt/blob/master/css/css-fonts/support/font-family-keywords.js

Some thoughts from the test results:

• Chrome:
  • If the family name is within the ASCII range, strip quotes, e.g. "emoji" -> emoji.
  • If the family name within quotes are the one of keywords, then don't remove quotes, e.g. "serif" -> "serif".
    It treats serif and "serif" as different family name.
• Firefox:
  • Leave the quoted family name as is, e.g. "serif" -> "serif", "emoji" -> "emoji".
• Safari:
  • If the family name is within the ASCII range, strip quotes, e.g. "emoji" -> emoji.
  • If the family name within quotes are the one of <generic-family> keywords, strip quotes in this case too, e.g. "serif" -> serif.
  • If the family name with -webkit- has standard, replace with the standard one, e.g.-webkit-serif -> serif.
  • For other family name with -webkit-, replace it based on the internal mapping, e.g. -webkit-body -> Times.

It's just my guess, but from the above results, I don't think any browsers have implemented emoji or fangsong as <generic-family> keywords.
They are simply treated as non generic family names.

Also note that emoji and fangsong without quotes are both valid family names, even if they are not in <generic-family>,
so all browsers are passing first Serialization of <generic-family> test.
But our implementation expects unquoted family name to start with upper case, so we failed emoji to pass.
See https://github.com/jsdom/cssstyle/blob/main/lib/properties/fontFamily.js#L28
We can remove this part, but it would make verification more difficult.

[domenic]

Thanks for the investigation! Upon reading the spec in more detail, I think the test should update https://github.com/web-platform-tests/wpt/blob/master/css/css-fonts/support/font-family-keywords.js to match the list in https://drafts.csswg.org/css-fonts-4/#generic-font-families . I will send a PR for that. (web-platform-tests/wpt#53015)

Analysis of the tests:

• Serialization of <generic-family>: the expectations match the spec. You parse as <generic-family> and that gets serialized back as a keyword.
• Serialization of quoted "<generic-family>": the expectations match the spec. You parse as <family-name>'s <string> branch, which serializes with quotes, and is separate from <generic-family>. See https://drafts.csswg.org/css-fonts-4/#ex-valid-unusual-generic-like .
• Serialization of prefixed -webkit-<generic-family>: the expectations match the spec. You parse as <family-name>'s <custom-ident>+ branch, which is kept as an identifier (since there are no spaces), and serialized back that way.
• Serialization of ${kNonGenericFontFamilyKeywords}: same as -webkit prefixes, these are all single <custom-ident>s.

For our implementation in cssstyle, I think the minimal change is to just update the keyword list to match https://drafts.csswg.org/css-fonts-4/#generic-font-families . (Maybe omit generic(*) if they are too complicated.) We should not include special casing for -webkit.

Eventually, we could write completely spec-compliant parsing and serializing code for font-families. This would involve removing the current uppercase assumption and instead using a parser that can recognize:

• keywords (for <generic-family>)
• strings (for one part of <family-name>)
• custom-idents (for the other part of <family-name>)

But this is probably much harder.

[asamuzaK]

Just to confirm, you will get a result like this:

style.font = "medium foo"; // no generic font family

console.log(style.fontFamily); // `foo`

It should be okay then?

[asamuzaK]

Updated the implementation, but omitted generic().
We need to implement a new parser to handle CSS functions like generic(), repeat() (see #146), and so on.

[domenic]

Just to confirm, you will get a result like this:

style.font = "medium foo"; // no generic font family

console.log(style.fontFamily); // `foo`

It should be okay then?

This appears to be how browsers behave, so yeah, that seems good!

[asamuzaK]

Fixed font shorthand too.
Ready for review.