CODEWITHSUNDEEP
htmlattributesbackwards-compatibilitycustom-elementlit-element
last-child
last-child

Reputation: 4871

Can a custom element use arbitrary attribute names safely?

There are very clear rules for how custom elements should be named. The main difference to other HTML elements is that they must have a non-leading hyphen. While it's possible to load an HTML document that includes made-up tag names that don't stick to these rules, it's supposed to guarantee a certain level of future-proofing and platform support.

However, I'm looking for guidance on how to name attributes for my custom elements. For readability and convenience I would prefer to use short, descriptive attribute names, e.g. not using a data- prefix for everything, but I also want to be sure things won't break as new features are added to HTML5. My research so far has not given any clear answers, and suggests that in practice, it's a bit of a wild west.

For example, the W3 HTML5 validator seems to accept made-up attribute names that follow basic conventions like using only a-z and hyphens, but only when they're used on custom elements. It complains about things like using special characters or repeating the same attribute, so that suggests that it's not simply giving up validation completely on a custom element, but actually considers arbitrary attribute names to be valid in that context.

Google's developer resources as a page Custom Element Best Practices, but as far as I can tell it does not answer this question. However, their examples seem to stick to using existing attribute names like checked and disabled. Examples from Google's web component-focused javascript library Lit seem to make use of arbitrary attribute names, however.

My question boils down to:

  1. What, if any, is the official word in the spec on how to name custom attributes for custom elements?
  2. If there's no official word, what is considered to be best practices? How can anyone using custom elements be sure that their attributes will not trigger unexpected functionality in future browsers?

Upvotes: 1

Views: 882

Answers (1)

Quentin
Quentin

Reputation: 943561

The specification defines the attributes accepted on a custom element as:

  • Global attributes, except the is attribute
  • form, for form-associated custom elements — Associates the element with a form element
  • disabled, for form-associated custom elements — Whether the form control is disabled
  • readonly, for form-associated custom elements — Affects willValidate, plus any behavior added by the custom element author
  • name, for form-associated custom elements — Name of the element to use for form submission and in the form.elements API
  • Any other attribute that has no namespace (see prose).

And then says

Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas. The exception is the is attribute, which must not be specified on an autonomous custom element (and which will have no effect if it is).

Customized built-in elements follow the normal requirements for attributes, based on the elements they extend. To add custom attribute-based behavior, use data-* attributes.

Upvotes: 2

Related Questions