[cssom] Adjacent space when serializing '/'

[ewilligers]

Each browser has variation in whether or not they include whitespace when serializing a '/' in shorthands (example):

Blink:
No spaces for specified font.
Spaces for resolved border-radius, font, grid, grid-template.

Edge 18:
No spaces for specified font.
Spaces for specified border-radius.

Firefox:
No spaces for specified font.
Spaces for specified border-radius, grid, grid-template, mask.

Safari:
No spaces for specified or resolved font.
Spaces for resolved border-radius, grid, grid-template.

Relevant spec: https://drafts.csswg.org/cssom/#serializing-css-values

[emilio]

Yikes, what a mess...

I think if possible we should try to use spaces everywhere. Tough given everyone agrees on "no spaces for specified fonts" we may want to special-case that one out. WDYT?

[tabatkins]

All of the cases are equivalent in parsing; so long as you don't have a * before or after the /, a / will always parse as a DELIM token.

For readability's sake, I do agree with always doing spaces. We can special-case 'font' if necessary, but I'd rather try for consistency first and special-case only if there are bugs.

[emilio]

Sure, I'm happy to make the change in Gecko if Blink is willing to do that too.

[ewilligers]

I would like gCS results to round-trip as specified values.

Changing Blink and WPTs for font shorthand to include spaces: https://chromium-review.googlesource.com/c/chromium/src/+/1800894

[emilio]

I have a patch to Gecko to update to this once WPT gets upstreamed: https://hg.mozilla.org/try/rev/1988d5f527709c4583d4b5315c50c65337fc6101

Note that another place where this character exists (in media queries for now) is <ratio>. It seems like Chrome and Firefox serialize it without spaces (matchMedia("(aspect-ratio: 1/3)").media), but I'd change both.