Allow custom-elements to be a labelable element without being form-associated.

[lukewarlow]

What is the issue with the HTML Standard?

Currently a custom element can opt-in to be a fully form-associated element via static formAssociated = true;, this comes with a few different bits of functionality. Firstly it makes the element labelable, but it also makes it so stuff like adding the disabled and readonly attributes have an effect. For example, pseudo-classes such as :disabled, :enabled, and :valid all match.

Some built-in elements are labelable but are not form associated, namely <progress> and <meter>. Should we expose this to custom-elements so they can get the labelable behaviour without the rest, to better match certain built-ins?

[domenic]

On the general principle of making custom elements as capable as built-ins, I am in support of this.

However, it is worth questioning whether this particular capability is actually a useful one. <progress> and <meter> are not the most-used elements ever, so I wonder how many web developers know about, or benefit from, this ability. If we were designing those elements today, would we judge the distinction important enough to split them and create a new labelable-but-not-form-associated category? Or would we instead just leave them un-labelable, or make them form-associated?

[lukewarlow]

That's a good question and definitely one worth answering. I'm honestly not sure.

Though I've also got a separate question (which I'll make into its own issue probably), why can we only label form associated elements (+ progress and meter). It seems at my naive first glance a weird restriction to have in the first place. In some ways I wonder if the list of labelable elements should be larger?