FF149 Allow more characters in DOM APIs

[hamishwillee]

FF149 adds support for additional characters to be allowed in attribute and element names in https://bugzilla.mozilla.org/show_bug.cgi?id=1773312.

Previously you could only use the chars allowed in XML names - now the rules are less restrictive to allow the same chars as the HTML parser.

Spec update: whatwg/html#7991

Chrome states support in 143:

• https://developer.chrome.com/blog/chrome-143-beta#allow_more_characters_in_javascript_dom_apis
• https://chromestatus.com/feature/6278918763708416

Webkit added support in https://bugs.webkit.org/show_bug.cgi?id=241419 but I don't think this made it to Safari yet.

Related docs work can be tracked in mdn/content#43218

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[hamishwillee]

I used this key and name here. We could instead do something like this. Is really a question "is the key and description reasonable".

Suggested change

	"relax_dom_valid_names": {
	"__compat": {
	"description": "Allow more characters in custom element names",
	"dom_names_match_html_parser": {
	"__compat": {
	"description": "Characters in custom element names match those allowed by HTML parser",

[caugner]

cc @ddbeck for thoughts on naming this spec evolution subfeature.

[ddbeck]

@hamishwillee can you give me an example of a name that would be invalid under the old spec and valid under the new spec? I think this would help me understand to best frame this subfeature.

[hamishwillee]

@ddbeck My perspective is the main benefit is that the character set allowed by HTML and DOM now match for namespace, element, and attribute names.

To answer your question, from the spec issue what I saw as likely most significant was allowing emoticons in names - so this is now valid my-🎉-element but would have been blocked by XML.

From Claude, a summary of the main differences including some tags that are now valid that were not before.

Name	Old (XML)	New (WHATWG)	Why significant
my!element	❌ InvalidCharacterError	✅ valid	! now allowed after letter start
my?tag	❌	✅	? now allowed
my(tag)	❌	✅	(, ) now allowed
my🎉tag	❌	✅	Emoji/post-Unicode-2.0 characters
tag=value (element)	❌	✅	= allowed in element names
_tag!	❌	❌	! still blocked after non-letter start
my tag	❌	❌	Whitespace always blocked
my>tag	❌	❌	> always blocked

[hamishwillee]

@ddbeck Did this answer your question?

[ddbeck]

Sorry for the delay responding to this, Hamish. This does answer my question. The link to the spec issue was especially helpful. (The Claude output was less so; I'd rather have your prompt in the future rather than a chatbot's output.)

The way I see it, real-world use cases are emoji or extended characters like the Dutch letter ij. Punctuation and parentheses seem like consequences of the change, rather than true features. Since Unicode is the most 'legible' bit of this, so I'm going to suggest something like this:

Suggested change

	"relax_dom_valid_names": {
	"__compat": {
	"description": "Allow more characters in custom element names",
	"html_name_validity": {
	"__compat": {
	"description": "Emoji and more Unicode in element names (valid names match HTML parser)",

I'm not so fussed on the specific wording here, I just want to make sure we frame in terms of features for developers (you can now do X) versus doing stenography for spec editors.

[hamishwillee]

Thanks @ddbeck - I take your point. Word are fine to me. I've fixed via search-replace