W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2018

[csswg-drafts] [cssom] Serialization of <family-name> doesn't match what browsers do

From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Feb 2018 06:51:43 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-299615742-1519368702-sysbot+gh@w3.org>
upsuper has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom] Serialization of <family-name> doesn't match what browsers do ==
The spec currently treats `<family-name>` the same way as `<string>`, which doesn't match what browsers currently do.

This is a simple page for showing what browsers currently do for `<font-family>`: https://jsfiddle.net/hzoazsqb/

(Note that, Firefox has [some bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1434802) around which was just fixed in 60, and that is also the reason I raise this issue.)

Basically, browsers all serialize `<family-name>` as identifier(s) sometimes. In Gecko, we try to preserve the original form of input as much as possible, unless we hit tricky case (e.g. escaped whitespace). Blink seems to always use identifier if it doesn't contain any whitespace, and use string when it contains any. Edge seems to preserve the original form but ignores the escaped white-spaces.

So browsers don't agree with each other, and they all disagree with the spec text. I guess we should have the spec fixed to allow serializing to identifier(s), and probably allow browsers to do whatever they want as far as the serialization is equivalent to what is specified.

Note that, it seems to me that Edge's behavior is wrong. `Foo\␣␣Bar` is a different value than `Foo␣␣Bar`. The latter is equivalent to `"Foo␣Bar"` while the former is `"Foo␣␣Bar"`, as far as I can tell from the spec. (This kind of case is tricky to handle so we decide to just use string for those cases in Gecko.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2350 using your GitHub account
Received on Friday, 23 February 2018 06:53:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:24 UTC