Reference Target: Clarify how JS Element attributes work with referenceTarget#1066
Conversation
Westbrook
left a comment
Westbrook
left a comment
There was a problem hiding this comment.
This explainer is getting closer and closer to spec text every time. Thanks for the added specificity!
| These will _always_ refer to the **host** element that they're targeting, and _never_ the referenceTarget element directly. This behavior maintains the design that an [IDL attribute with type Element](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element) can only refer to an element that is a descendant of a [shadow-including ancestor](https://dom.spec.whatwg.org/#concept-shadow-including-ancestor) of the element hosting the attribute. | ||
| These will _never_ directly return the referenceTarget element that's inside the shadow tree. This is because an [IDL attribute with type Element](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element) can only refer to an element that is a descendant of a [shadow-including ancestor](https://dom.spec.whatwg.org/#concept-shadow-including-ancestor) of the element hosting the attribute. | ||
|
|
||
| Instead, most attributes return the **host** element that they're targeting, as long as the attribute's expected type is `HTMLElement`. However, The `.form` and `.list` attributes will return `null` when used with a referenceTarget, because they are expected to be `HTMLFormElement` or `HTMLDataListElement` and the host element itself is not a form or datalist. Importantly, the underlying association will still exist: the input will be connected to the form, for example; it's just not reflected by the `.form` attribute. |
There was a problem hiding this comment.
This feels a little odd, doesn't it? There is a form/list reference, and it's valid, but the JS accessor returns null. Perhaps it'd be better to have the IDL for form and list return HTMLElement (or even Element?)?
I suppose there are likely web compat issues with this, of some variety.
There was a problem hiding this comment.
Yeah I agree it seems odd. My main concern was worrying not to break the web by changing the return type to HTMLElement instead of HTMLFormElement/HTMLDataListElement. That said, the change would only affect new scenarios that were previously not possible, and it should not affect existing code as far as I can tell. It would be good to have an expert weigh in on the potential problems with changing the IDL return types in the new scenarios.
There was a problem hiding this comment.
Do you want to hold this PR for this feedback or open a new PR once we've heard from other implementors about possible issues here?
There was a problem hiding this comment.
I think it would benefit from further discussion, but I don't think it should block this PR for now. I logged #1072 to discuss the follow-up options. Depending on the outcome of the discussion, another PR could be made to update this section.
There was a problem hiding this comment.
Sounds good. Thanks Ben!
3 participants
Update the JavaScript attributes that reflect
Elementobjects to clarify which attributes return the host element. Also, add special cases for the.formand.listattributes, which returnnullbecause their types don't allow returning the host element.