JavaScript whitespace [1], as observable through `\s` in regular
expression patterns or string methods such as `.trim()`, matches the
following code points:
- U+0009 CHARACTER TABULATION
- U+000A LINE FEED (LF)
- U+000B LINE TABULATION
- U+000C FORM FEED
- U+000D CARRIAGE RETURN (CR)
- U+0020 SPACE
- U+1680 OGHAM SPACE MARK
- U+2000 EN QUAD
- U+2001 EM QUAD
- U+2002 EN SPACE
- U+2003 EM SPACE
- U+2004 THREE-PER-EM SPACE
- U+2005 FOUR-PER-EM SPACE
- U+2006 SIX-PER-EM SPACE
- U+2007 FIGURE SPACE
- U+2008 PUNCTUATION SPACE
- U+2009 THIN SPACE
- U+200A HAIR SPACE
- U+2028 LINE SEPARATOR
- U+2029 PARAGRAPH SEPARATOR
- U+202F NARROW NO-BREAK SPACE
- U+205F MEDIUM MATHEMATICAL SPACE
- U+3000 IDEOGRAPHIC SPACE
- U+FEFF ZERO WIDTH NO-BREAK SPACE
CSS whitespace [2] on the other hand is much more limited:
- U+000A LINE FEED (LF)
- U+0009 CHARACTER TABULATION
- U+0020 SPACE
Additionally, CSS pre-processing [3] normalizes any of the following to
U+000A LINE FEED (LF):
- U+000C FORM FEED
- U+000D CARRIAGE RETURN (CR)
- U+000D CARRIAGE RETURN (CR) followed by U+000A LINE FEED (LF)
Prior to this patch, we were implicitly using JavaScript-specific
definitions of “whitespace” to process CSS source text, resulting in
several issues, of which the reported bug is just one example.
With this patch, we now correctly consider CSS’s definition of
“whitespace” when processing CSS source text.
[1]: https://tc39.es/ecma262/#prod-WhiteSpace
[2]: https://drafts.csswg.org/css-syntax/#whitespace
[3]: https://drafts.csswg.org/css-syntax/#input-preprocessing
Bug: chromium:1193337
Change-Id: Iaeadbd4b033dbce9a5b03bd22c2cc6c0a60f8016
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2831439
Reviewed-by: Changhao Han <changhaohan@chromium.org>
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Tim van der Lippe