Re: [WICG/webcomponents] Reference Target: What about IDL attributes? (Issue #1089)

I'm not quite sure I follow your answers, sorry @annevk.

The question I was trying to ask in the issue description, which I didn't explain very well in hindsight, was whether relationships set via Element IDL attributes (as opposed to content attributes which necessarily use ID strings) should also follow reference target forwarding when computing the relationships. 

The explainer doesn't address this; it only says:

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

and

> These [IDL attribute getters] will _never_ directly return the referenceTarget element that's inside the shadow tree. 

While the explainer doesn't address how the IDL attribute setters should work, the WPTs indicate that the intent was for attribute set via IDL attributes to work similarly to attribute set via content attributes.

The explainer is clear on how the IDL attribute getters should work when the referenceTarget is valid; they should return the element in the appropriate scope (i.e. the element which was set via the setter, which must be a descendant of a shadow-including ancestor of the element hosting the attribute).

> I think APIs should generally return the custom element (that handles the forwarding into its shadow tree). It seems weird if the APIs didn't work just because you used a custom element (with forwarding).

When you say the APIs should return the custom element, are you answering the later question in https://github.com/WICG/webcomponents/issues/1089#issuecomment-2533164216, regarding whether the IDL attribute getters should return null/empty list for an invalid referenceTarget?

> This might also duplicate https://github.com/WICG/webcomponents/issues/1071?

The reason I think that this is a slightly different question to #1071 is that #1071 (part 2) uses a getter-only API as an example. #1071 seems to conclude that an invalid referenceTarget is analogous to a bad ID, so even if the ID reference to the host is valid, the attribute is invalid. Because the attribute is invalid, the IDL getter returns null, just as it would if the content attribute was a bad ID.

With an IDL attribute setter, there is no ID involved, so I think you could make an argument that you should get back the element that you set, assuming that element is a descendant of a shadow-including ancestor.

However, I think you could also make an argument that it should only return the element that you set if it is also a _valid_ value, per my reasoning below. This would be analogous to how you can _set_ an IDL attribute to be an element that is not a descendant of a shadow-including ancestor, but it won't be returned from the getter.

> For the later question I think we have to answer another question. When do we consider a custom element a viable ID target?

I think a custom element can be a viable ID target when either:

1) It is, itself, a viable ID target, and doesn't have a referenceTarget set. 
   For example:
   ```html
   <button popovertarget="custom">Show popover</button>
   <custom-popover id="custom">
     <template shadowrootmode="open">
       <!-- no referenceTarget -->
       Some popover content.
     </template>
   </custom-popover>
   ```

2) Or, it contains a viable ID target, and has a valid referenceTarget set referring to the viable target.
   For example:
   ```html
   <label for="custom">Given name</label>
   <custom-input id="custom">
     <template shadowrootmode="open" shadowrootreferencetarget="real-input">
       <input id="real-input">
     </template>
   </custom-input>
   ```
   
   Without the referenceTarget forwarding to the `<input>`, `custom` is not a valid target for `for`, as it is not a labelable element. It would be equally invalid whether the referenceTarget was missing, or was a bad ID, or referred to an element which was not a labelable element.

> It seems potentially somewhat performance-sensitive to do 3, but not sure.

Depending on the implementation, this could be performance sensitive when resolving an ID target (note that this is different from either `getElementById()` or a query selector), or require extra storage to keep track of both the "shallow" and the "deep" version of each ID reference, plus update them on relevant mutations. However, I think in practice the performance difference should be negligible. It would at worst require a small number of extra lookups (two per shadow root - one to check the presence of a referenceTarget, and one to resolve it) when using certain DOM APIs.

Regardless of the decision we make for DOM APIs, we will still need to implement that validity logic for whatever the consequences are of the relation. For example, a `for` attribute on a `<label>` only has any effect when it refers to a labelable element. When determining the activation behaviour of the `<label>`, we will still need to determine what "deep" element it refers to.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1089#issuecomment-2537479000
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1089/2537479000@github.com>