[css-syntax-3] `non-ASCII ident code point` might be breaking because it excludes the use of emojis in idents

[romainmenke]

As always, I might just have a bug :)

After implementing https://drafts.csswg.org/css-syntax/#non-ascii-ident-code-point I had a bunch of test failures because emojis are no longer valid in idents.

This works today in all browsers :

:root {
	--💅: hotpink;
}

body {
	background-color: var(--💅);
}

I don't think writing CSS like this is a good idea, but I know that we have had reports about it not working for people, so that is at least an indicator that someone did something like this.

postcss/postcss-custom-properties#237

---

If it is correct that these codepoints are no longer valid in idents it might be needed to check if this will break more than just a few experiments by people.

[romainmenke]

'💅'.charCodeAt(0).toString(16);
// 'd83d'

'💅'.charCodeAt(1).toString(16)
// 'dc85'

Seems like there are a lot of these in between these two range :

between U+3001 and U+D7FF
between U+F900 and U+FDCF

[tabatkins]

Those are not codepoints that you're looking at.

"💅".codePointAt(0).toString(16)
// '1f485'

The Syntax spec runs on a stream of code points, but JS naively returns code units, which are limited to the range 0-ffff. To encode any higher code points JS splits them into two code units using the reserved surrogate range, from d800-dfff. You have to account for this when parsing strings from JS. (My parser just eagerly converts the whole string into an array of codepoints, but these days you can do that more easily with an Array.from(str, cp=>cp.codePointAt(0)) call, since the iterator protocol on strings advances by codepoint.)

[romainmenke]

Awesome!
I was hoping this was a bug on my end.

🙇