[css-syntax] Missing emoji in non-ascii identifier codepoints

[Conaclos]

Type of proposal: enhancement

The non-ASCII ident code point specification doesn't include the Miscellaneous Symbols Unicode block, and the Dingbats Unicode block. However, the emoji of these blocks are allowed by browsers.

Note: should we also accept some of the emoji of the Miscellaneous Technical Unicode block? Or should we even accept all non-ASCII characters?

These codepoints (0+2600 to U+27BF included) could be added to the non-ASCII ident code point specification.

[tabatkins]

As stated in the spec's note, I just matched HTML's set of valid custom element name characters. We want CSS's idents to at least cover that set, so authors don't have to use escapes when writing selectors to target their custom elements, but we could be a superset.

I'm checking with the HTML editors to see if they remember why these specific ranges were chosen, and if there's a good reason to avoid allowing those emojis. (cc @annevk @domenic )

It does indeed seem a little silly that --🥔 is a valid custom property name, but --✨ isn't.

[tabatkins]

Or should we even accept all non-ASCII characters?

Not all; again, as stated in the note, there's good reasons to exclude some characters from idents, and Unicode itself even recommends disallowing some characters that are allowed by the current spec. But the emojis seem probably safe.

[annevk]

We actually want to turn it into a blocklist of sorts: whatwg/dom#1079. The current restrictions follow from XML (which the DOM APIs build on and with which we wanted to be compatible): https://www.w3.org/TR/REC-xml/#NT-NameStartChar

I think it would be okay for CSS to essentially have one or more ASCII alpha or U+0080 through U+10FFFF (and maybe some other ASCII code points?), as long as it starts with two hyphens. No need for HTML parity.

[Conaclos]

Do you have a timeframe for a decision? What safe assumptions can I make from an implementer pov?

[tabatkins]

No timeframe yet; in particular, I'm missing this week's telcon.

Until you actually see movement in implementations, don't make any assumptions that things will change; continue to treat the valid syntax space as what's in the speed.