[css-om] Serialization of font-family names: quoted string vs keyword

[jfkthame]

According to 6.7.2. Serializing CSS Values, the serialization of a font-family name should be "The string serialized as a string", where this means a string surrounded by literal ASCII double-quotes (and with any internal double-quotes or backslashes escaped).

However, AFAICT no browser consistently follows this.

For a family-name that is a single word (without special characters that would require quoting to be parsed), WebKit/Blink prefer to serialize the name as an unquoted keyword.

For example, from Safari's Javascript console:

> document.body.style.fontFamily = "'Times'"
< "'Times'"
> document.body.style.fontFamily
< "Times"

Note that the name is returned without quotes (even though it was specified as a quoted string).

Now try a multi-word family name:

> document.body.style.fontFamily = "'Times New Roman'"
< "'Times New Roman'"
> document.body.style.fontFamily
< "\"Times New Roman\""

Here, the result is quoted.

Furthermore:

> document.body.style.fontFamily = "Avenir Next"
< "Avenir Next"
> document.body.style.fontFamily
< "\"Avenir Next\""

Even when the family name was specified without quotes, Safari adds them. (At least it seems consistent.)

Firefox takes a different approach; it seems to serialize the name according to how it was specified. So a name specified in unquoted form:

> document.body.style.fontFamily = "Times"
< "Times"
> document.body.style.fontFamily
< "Times"

serializes as such, while the same name, quoted:

> document.body.style.fontFamily = "'Times'"
< "'Times'"
> document.body.style.fontFamily
< "\"Times\""

returns a serialization that also has the quotes.

This holds for multi-word names, too; even then, Firefox returns an unquoted serialization if the name was specified in that form:

document.body.style.fontFamily = "Times New Roman"
"Times New Roman"
document.body.style.fontFamily
"Times New Roman"

So my question is whether implementers have any interest in aligning with the CSSOM spec here, in which case these are simply browser bugs to be fixed; or should the spec be adjusted to more closely match implementation reality?

[emilio]

Gecko's code was originally implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1434802 (following even longer-standing behavior) and then got a few tweaks in https://bugzilla.mozilla.org/show_bug.cgi?id=1614348. I think the biggest constraint here is compat, and I'm a bit skeptic about the spec being compatible here... But happy to be proven wrong, this should be very easy to implement behind a flag and check for breakage...

[litherum]

Is this a source of bugs?

If not, we should just relax the requirement and say something like it has to be outputted in a form that round-trips.

[fred-wang]

Blink basically does not add quote to a <family-name> iff it can be parsed as a CSS minus backslash-escape sequences:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/css_markup.cc;l=145;drc=0a7ae0e6c7f507bf4d102df97e733628566b4736

There is a bug though : "serif" (with quotes i.e. <font-family>) becomes serif (without quotes i.e. <generic-family>) when serialized. See the two second case of

https://w3c-test.org/css/cssom/font-family-serialization-001.html

But it's easy to fix by always adding quotes if the name is the same as a <generic-family>.

I think the spec should clearly specify how to serialize font-family if it is different from a comma-separated list of identifiers/strings.

[fred-wang]

But it's easy to fix by always adding quotes if the name is the same as a <generic-family>.

It's also necessary to add quotes for font names that are the same as global values:

font-family: "initial"
font-family: "inherit"
font-family: "unset"
font-family: "revert"
font-family: "default"

[cdoublev]

I am asking in this issue because it seems to be the most active, but it is a duplicate of #2350: for specified value, why not just serialize as specified by the author? Retaining more details of what the author originally wrote seems to be an implicit principle for specified values.

Is it because browsers have to compare "foo" and foo to figure out at parse time that it is the same family (or keyframe/animation) name?