[prop/types] Element type

[LeaVerou]

A very common pattern is to have attributes that reference another element. E.g. examples from native HTML:

• Popovers (popovertarget)
• Invokers (invoketarget)
• A host of ARIA attributes (e.g. aria-describedby, aria-labelledby, aria-activedescendant, aria-controls, aria-details, aria-flowto, aria-owns etc.)
• for, in <label> and <output>
• list in <input>
• the new anchor attribute

Currently, Nude Element doesn’t support this use case well.

The question is also, what syntax to use? Usually in these cases we want to be consistent with the host language (in this case HTML). However, HTML has pretty terrible ergonomics around this so we should not just support that (though ids could be a good MVP as they’re much easier to implement).

Some settings we could support (names TBB):

• Value: identifier, selector, maybe keyword?
• if identifier:
  • attribute that is matched (id, name, data-property, the sky is the limit).
  • scoping attribute(s)
• Matching strategy: first matching element across the tree vs iterative scoped querySelector() calls walking from the element to its root node vs iterative scoped calls walking up scopes (if a scoping attribute is provided). Iterative allows referencing relative identifiers but is slower.

This is also another case where we want to have a prop for the textual input, AND a prop for the actual resolved value (the Element object). HTML is pretty inconsistent with naming here, or even whether such a property exists:

• control for for in labels, nothing for `
• popoverTargetElement for popovertarget
• ariaDescribedByElements for aria-describedby (and similar for other ARIA attributes)
• list for list on <input>, shadowing the actual string value provided, which doesn't seem to be accessible via any property name.

I see two reasonable paths:

1. Default to propName + "Element" as a default for this prop (or propName + "Elements" if its a child type), and provide a setting to customize it if a different property name is desired
2. Default to replacing the string value and provide a setting for specifying a separate property

As a side note, there seems to be a host of these use cases, and perhaps we should support this pattern out of the box by having an option for which prop the parsed value should go in. I may file a separate issue for that.