I think we might want to be a bit more explicit about which attributes should be in scope for this feature.

l think I understand the reasoning behind wanting all attributes [1] to be in scope: I imagine it would be easier to explain that this is simply how ID/reference attributes work, in general. Also, adding an existing attribute into the scope of attributes which support referenceTarget after the feature ships would be a breaking change.

However, there are at least two attributes which seem to me to be potentially out of scope, and I don't see any WPT tests for them:

• headers on <td>/<tr> (listed in the explainer as being in-scope)
• itemref - a global attribute used in Microdata (not listed in the explainer)

If we did exclude those attributes, we would need to consider how to:

1. explain to developers why some attributes don't follow referenceTarget forwarding
2. consider how any future attributes should opt in or out of referenceTarget behaviour.

--

[1] The explainer states:

This feature is intended to work with all attributes that refer to another element by ID string. These are:

• ARIA
  • aria-activedescendant
  • aria-controls
  • aria-describedby
  • aria-details
  • aria-errormessage
  • aria-flowto
  • aria-labelledby
  • aria-owns
• Inputs
  • for (also supports the click behavior of labels)
  • form
  • list
  • popovertarget
  • anchor (proposed in the Popover API Explainer)
  • commandfor (proposed in Invokers Explainer)
  • interesttarget (proposed in Invokers Explainer)
• Tables
  • headers