u + a selector is minified to u+a

[romainmenke]

Describe the bug

u + a {
  color: green;
}

becomes :

u+a{color:green}

Expected behaviour

I expected cssnano to avoid forming <urange> tokens.

https://www.w3.org/TR/2021/CRD-css-syntax-3-20211224/#urange-syntax

There are likely more error cases.

Steps to reproduce

https://cssnano.co/playground/#eyJpbnB1dCI6InUgKyBhe2NvbG9yOmdyZWVufSIsImNvbmZpZyI6ImNzc25hbm8tcHJlc2V0LWRlZmF1bHQifQ==

Version

playground version

Preset

default

Environment

playground

Package details

playground

Additional context

No response

[ludofischer]

So we should skip removing whitespace when the selector starts with u followed by +? I suppose it's not that common in the wild because the u element is not popular.

[alexander-akait]

@ludofischer Intresting... Also intresting - firefox and safari work good without spaces (only chrome)

@tabatkins Hello, maybe you can clarify this, should we report it to chrome?

[romainmenke]

Found out a bit more in the mean time : parcel-bundler/lightningcss#289 (comment)

https://wpt.fyi/results/css/css-syntax/urange-parsing.html?label=master&label=experimental&aligned&view=subtest&q=urange

https://github.com/web-platform-tests/wpt/blob/09b8d2f86a/css/css-syntax/urange-parsing.html

If I read those tests correctly the parser/tokenizer should only form <urange> in certain contexts.

• Chrome is incorrectly parsing u+a {}.
• Safari and Firefox are correct.

parcel-bundler/lightningcss#289 (comment)

There is also already a chromium bug related to those WPT tests : https://bugs.chromium.org/p/chromium/issues/detail?id=1215071&q=urange%20css&can=2

[tabatkins]

Yes, we fixed this issue in the CSS Syntax spec a long time ago, so it should be considered still a browser bug when it causes a problem.

[alexander-akait]

@tabatkins Big thanks 👍