HTML has several content attributes which associate two elements with each other:

• label's for (single element)
• output's for (multiple elements)
• button/fieldset/input/object/output/select/textarea's form (single element)
• input's list (single element)

Right now these are reflected into IDL attributes in a variety of ways:

• label's for: DOMString IDL attribute directly reflecting the attribute
• output's for: DOMTokenList IDL attribute directly reflecting the attribute
• button/fieldset/input/object/output/select/textarea's form: readonly HTMLFormElement? IDL attribute that computes the form element in question
• input's list: readonly HTMLElement? IDL attribute that computes the datalist element in question

We'd like to add a way for these kind of element associations to be done across shadow trees, and without depending on IDs. The basic idea is that we'd like to add a read-write labelEl.htmlForElement property; by setting it, you can create the label association for any element.

The details of this are a bit tricky. We used to have one model for this, used by the contextMenu global IDL attribute, but that was only ever implemented in one browser, and removed in f0f7a14. Nevertheless, it provides a good precedent. Some questions to answer when developing such a model (not exhaustive):

• What happens to inputEl.htmlFor and the for="" content attribute if inputEl.htmlForElement is set to...
  • ... an element with an ID...
  • ... an element with no ID...
  • ... and the for="" content attribute was previously set
  • ... and the for="" content attribute was not previously set
• Similar questions for outputEl.for, complicated by it being a DOMTokenList instead of a DOMString

I believe @alice and others had a proposed model for this. It's worth comparing it with the model in the commit that was removed.

The other tricky part is figuring out how to integrate with the readonly variants currently in place for button/fieldset/input/object/output/select/textarea's form and input's list. Can we extend them to be read-write with general semantics? I'm not sure. Also they don't end in Element :-/. Maybe they aren't as important to worry about, compared to label's for?

One big motivation for this is that ARIA would like to add cross-shadow-root-capable, non-ID-based element reflection for many of its properties. This will require both single-element (input's for) and list-of-elements (output's for) reflection.