Using suffix Element/s for IDL attributes referring to elements

[mrego]

ARIA IDL still doesn't include attributes that refer to elements, but AOM IDL doesn't use any suffix for those attributes (e.g. ariaActiveDescendant or ariaDescribedBy).

However Chromium implementation and the AOM explainer use suffix Element or Elements for them (e.g. ariaActiveDescendantElement or ariaDescribedByElements).

What's the expected naming for these attributes? Thanks!

[nolanlawson]

It looks like #920 replaced the string reflection (e.g. ariaActiveDescendant) with element reflection (e.g. ariaActiveDescendantElement) and then #1260 removed the element reflection (by commenting it out).

From our (Salesforce Lightning Web Components) perspective, it seems sensible to support both the element reflection and the string reflection. The element reflection is necessary to support relationships that cross shadow root boundaries. Whereas the string reflection resolves some inconsistencies in how property reflection works across aria-* attributes. (Currently, element.ariaLabel can be used as a substitute for element.getAttribute('aria-label'), but element.ariaLabelledBy does not work as a substitute for element.getAttribute('aria-labelledby').)

Both the element and the string reflection can be supported simultaneously, thanks to the fact that the element reflection always has an Element or Elements suffix.

[mrego]

JFTR, there have been previous discussions around the possibility of having both string and element reflection in whatwg/html#3515 (comment)

[nolanlawson]

Thanks for the context. My proposal seems to be "option # 1" from Alice's comment.

[nolanlawson]

Just to summarize my preference (since whatwg/html#3515 has a lot of discussion, much of from before element reflection took its current shape), I would prefer for these two to be equivalent in every way:

element.setAttribute('aria-labelledby', 'foo')
element.ariaLabelledBy = 'foo'

And these two as well:

console.log(element.getAttribute('aria-labelledby'))
console.log(element.ariaLabelledBy)

In other words, I'm proposing for properties like ariaLabelledBy to not attempt to solve any thorny issues with ID refs (e.g. massaging them, changing when the element ID changes), but simply to be a shorthand for setAttribute() and getAttribute(). As far as I can tell, this defines them the same way as the other string attribute reflections (e.g. aria-label/ariaLabel).

This gives us consistency across the board at the expense of maybe allowing the properties to provide some better ergonomics than simply setting/getting the attribute.