validator
Allow custom element names in conformance with the current spec requirements
Spec URL
https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name | https://dom.spec.whatwg.org/#valid-element-local-name
Test case
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en" dir="ltr">
<head>
<meta charset="UTF-8"/>
<title>Custom Element Demo</title>
</head>
<body>
<andy-custom:menu></andy-custom:menu>
<script>
class AndyCustomMenu extends HTMLElement {
constructor() {
super();
this.attachShadow({ mode: "open" });
this.shadowRoot.innerHTML = `
<style>
div {
padding: 10px;
background: #eef;
border: 1px solid #99c;
font-family: sans-serif;
}
</style>
<div>Menu personalizzato</div>
`;
}
}
// Registrazione del custom element
customElements.define("andy-custom:menu", AndyCustomMenu);
</script>
</body>
</html>
Using colon in custom element names may have been an unused practice.
But HTML specs only require:
- A valid custom element name
- A local name
- A constructor
A string name is a valid custom element name if all of the following are true:
- name is a valid element local name;
- name's 0th code point is an ASCII lower alpha;
- name does not contain any ASCII upper alphas;
- name contains a U+002D (-); and
- name is not in a list of previously used hyphenated element names
The "valid element local name" bit refers to the DOM spec, which states that a string name is a valid element local name if the following steps return true:
- If name’s length is 0, then return false.
- If name’s 0th code point is an ASCII alpha, then:
- If name contains ASCII whitespace, U+0000 NULL, U+002F (/), or U+003E (>), then return false.
- Return true.
- If name’s 0th code point is not U+003A (:), U+005F (_), or in the range U+0080 to U+10FFFF, inclusive, then return false.
- If name’s subsequent code points, if any, are not ASCII alphas, ASCII digits, U+002D (-), U+002E (.), U+003A (:), U+005F (_), or in the range U+0080 to U+10FFFF, inclusive, then return false.
- Return true
This spec even allows for a valid element local name to start with a colon (explicitly listed among allowed characters).
Four possible cases:
- DOM spec is incorrectly referred
- HTML spec is meant to add further restrictions (as in, excluding non-blacklisted "valid local names" that either do not start with a lowercase letter, or contain uppercase letters, or do not contain hyphens, or contain colons.
- The specs work as intended, but there are use cases where using a colon in custom name can break code, therefore the feature is allowed but not recommended
- The specs work as intended and there's no reason to prevent colon, thus reconciling a formal namespace use with HTML hypen-flavoured bad copy.
The discrepancy appears to be due to https://github.com/whatwg/dom/commit/eb96fb7d2c91c7f4dcaf4e55670d29b12c60b0b0 from earlier this year — which changed the requirements to allow the colon and probably some (many?) other characters that weren’t allowed previously.
What’s allowed currently in the checker is limited to what the requirements were 9 years when I first implemented this — and I think that essentially amounted to requiring the element names to match the Name production in the XML spec.
This is reasonable and I had figured the change had been made in the DOM specification.
However, I checked some browsers and they still haven't implemented the change in allowed characters for custom names. If the alert gets changed, I suppose it should keep track of reality as well.
OK, yeah, at https://github.com/whatwg/dom/pull/1079 there’s a list of related browser bugs:
- https://issues.chromium.org/issues/40228234
- https://bugzilla.mozilla.org/show_bug.cgi?id=1773312
- https://bugs.webkit.org/show_bug.cgi?id=241419
And from looking at those, it seems the engine changes have been implemented in Blink, but not yet in Gecko or WebKit.
So I think before we make any change in the checker behavior, we’d want at least one more engine to have implemented it.