Consider restricting custom element names to ASCII

[dominiccooney]

Disclosure: I am filing this bug report on behalf of someone else; the following is a paraphrase:

Consider disallowing stuff outside ASCII in potential custom element names in v1. Permitting emoji and random latin1 stuff in there makes checking whether an element name is a potential element name much slower.

If I do some digging Blink may be able to quantify this, although I believe the cost of checking these names to be a small part of, for example, creating an element, loading a page, etc.

[domenic]

This was previously discussed at WICG/webcomponents#239 where we reached consensus on the current semantics. To reopen that discussion we'd probably want to see some data, indeed; it would be great to get an idea whether a custom elements heavy page (using only ASCII) performs significantly slower in some way with the current semantics vs. ones that only permit ASCII.

[annevk]

Also, presumably you could have ASCII-only fast paths.

[rniwa]

I don't understand this. You'd have to perform the same name validation check for when creating a HTMLUnknownElement. The only thing custom element adds is checking uppercase ASCII and -, both of which are pretty cheap to perform.

[domenic]

Let's close this pending any further data that shows it would be so beneficial as to be worth the breakage.