Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reference Target: Should the form and list JavaScript attributes return the host element? #1072

Open
behowell opened this issue Aug 22, 2024 · 2 comments

Comments

@behowell
Copy link
Contributor

This question was brought up by @mfreed7 in #1066 (comment).

In the JavaScript attributes that reflect Element objects section of the Reference Target Explainer, it describes how JavaScript attributes should return the host element, and not their reference target directly.

There are two attributes where this doesn't work today, because they are expected to return a specific element type:

  • The .form attribute always returns a HTMLFormElement.
  • The .list attribute always returns a HTMLDataListElement.

In the following example, the submit button is successfully linked to the <form id="real-form"> via the reference target. The question is what should the .form JS attribute return?

<button id="submit" type="submit" form="fancy-form">Submit</button>
<fancy-form id="fancy-form">
  <template
    shadowrootmode="open"
    shadowrootreferencetarget="real-form"
  >
    <form id="real-form"></form>
  </template>
</fancy-form>

<script>
  const submit = document.getElementById("submit");
  console.log(submit.form); // << What does this log?
</script>

There are a few possible options:

  1. The .form and .list always return null when used with a reference target. This way they never return something that's not the expected type.
  2. Update .form and .list to be able to return any HTMLElement if (and only if) it has a reference target set.
  • Although changing the return type for an attribute seems to have the possibility of breaking existing web pages, option 2 would only apply to net-new scenarios, and no web pages would be affected until they start using reference targets.

--

If we go with option 2, then that opens a secondary question that is related to the question posed in #1071:

What should it return if the reference target is not a valid HTMLFormElement/HTMLDataListElement? For example:

<button id="submit" type="submit" form="not-a-form">Submit</button>
<x-div id="not-a-form">
  <template
    shadowrootmode="open"
    shadowrootreferencetarget="real-div"
  >
    <div id="real-div"></div>
  </template>
</fancy-form>

<script>
  const submit = document.getElementById("submit");
  console.log(submit.form); // << What does this log?
</script>

The options are:
2a. It returns null. Even though it refers to a valid host element, which has a valid reference target, the target element is the wrong type and there is no underlying association. This is the same as if you set the form="" attribute to something that's not a <form>.
2b. It returns the host element. Presumably this would only happen if we went with Option 1b from #1071.

@behowell
Copy link
Contributor Author

I like option 2a the best, as long as changing the return type of those attributes can be done in a way that doesn't break the web.

@dandclark
Copy link
Contributor

dandclark commented Aug 22, 2024

The behavior of the HTMLLabelElement.control property should also follow whatever is decided here regarding 2a/2b. Its type is already HTMLElement, but the underlying association that it reflects can only be with a labelable element. In the Blink reference target prototype the behavior currently implemented for HTMLLabelElement.control is 2a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants