How to implement and shape API for `<selectedoption>` element for `<select>`

[josepharhar]

In the proposed appearance:base improvements for <select>, we want to support the use case of rendering the full DOM contents of the currently selected <option> into the select's button and let the author style it differently from the way it is styled in the <option> without the use of script.

The currently proposed way to support this, as designed in OpenUI, is to have a <selectedoption> element which copies contents from the selected <option> and replaces its children with those contents every time that the selected <option> changes.

There have been two ways of doing this which have been discussed:

1. Call cloneNode on the selected <option>, and replace the light DOM children of <selectedoption> with the result of cloneNode.
   • Authors can style the <option> and <selectedoption> separately by selecting for those elements in their selectors. Since the cloned contents are in the light DOM, there is no new syntax needed.
2. <selectedoption> has a UA shadowroot. Call cloneNode on the selected <option>, and replace the contents of the <selecedoption>'s shadowroot with the cloneNode result. Since this could leak the shadowroot, we will use the proposed sanitizer API on the cloneNode result before appending it to the shadowroot. In order to let authors style all the content in the shadowroot, we will create a pseudo element which goes to the content of the UA shadowroot, and add new syntax to CSS to allow for these descendants of the pseudo element to be selected.

Here's a quick example which shows the usecase and what the API would be like in solution 1 vs solution 2. It is a country picker where we only want to render the picture of the country flag in the button without the text next to it in the dropdown.

<select>
  <button type=popover>
    <selectedoption></selectedoption>
  </button>
  <datalist>
    <option>
      <img src="country1.jpg">
      <span>Country 1</span>
    </option>
    <option>
      <img src="country2.jpg">
      <span>Country 2</span>
    </option>
  </datalist>
</select>

Solution 1 CSS:

selectedoption > span {
  display: none;
}

Solution 2 CSS:

selectedoption::selectedoption-content > span {
  display:none;
}

This topic was previously discussed here: #9284

[tabatkins]

Just curious - is there a reason this was split from #9284? If it was just to reset the conversation given a more stable design from HTML/OpenUI, should we close #9284?

---

I don't have a strong opinion between these two. I'm happy that we seem to have settled on "copy the DOM over" in both solutions, and are just debating whether it should be visible in the light DOM or hidden by a UA shadow; that makes many potential questions much easier to answer.

The Selectors spec is already equipped to handle Option 2, if we want: see Pseudo-elements/internal structure and the <complex-selector> grammar. This would be the first pseudo-element to actually use that syntax.

I suspect we might want Option 2, not for CSS reasons, but just for DOM reasons - it avoids the need to answer questions about mutation events and the like (I think those are censored by shadows? especially UA shadows?)

[josepharhar]

Just curious - is there a reason this was split from #9284? If it was just to reset the conversation given a more stable design from HTML/OpenUI, should we close #9284?

Yeah I think we can close #9284 in favor of this.

it avoids the need to answer questions about mutation events and the like (I think those are censored by shadows? especially UA shadows?)

We could just disable mutation events during the scope of this DOM copying. We are trying to disable mutation events entirely anyway, so disabling them in this case sounds very reasonable to me.

Another question I have if we go with option 2: The pseudo-element would have to target the ShadowRoot node in order to access all of its children independently. Is it possible to have a pseudo-element map to a ShadowRoot node which is technically not an element?

[tabatkins]

We could just disable mutation events during the scope of this DOM copying. We are trying to disable mutation events entirely anyway, so disabling them in this case sounds very reasonable to me.

Ah, true, that makes sense. Then that's not a factor either way, I'd think.

Another question I have if we go with option 2: The pseudo-element would have to target the ShadowRoot node in order to access all of its children independently. Is it possible to have a pseudo-element map to a ShadowRoot node which is technically not an element?

Yes, that's conceptually fine. It's just an "element" that is prevented from ever generating a box.

But the inheritance story is a little funky in that case. Would the elements inherit from the pseudo-element? That hasn't happened before (only pseudo-to-pseudo), and I'm not sure if it's problematic in implementations or not. Just using light-DOM children instead avoids us having to answer any of these questions.

[annevk]

How often is cloning done when an option (that's also the selected option) is being mutated? I.e., what is the timing story. And if you mutate the selected option, is that reflected?

I'm also wondering about the timing of the first time an option gets cloned when the end user hasn't made a choice yet.

[josepharhar]

How often is cloning done when an option (that's also the selected option) is being mutated? I.e., what is the timing story.

Right now my prototype does it synchronously but I'd like to try building on MutationObserver which from my understanding is like microtask timing right?

And if you mutate the selected option, is that reflected?

If the selected <option> has any descendant mutated, then yeah we want that to trigger a clone into <selectedoption>. If the author mutates the contents of <selectedoption> then I'm not planning on doing anything.

I'm also wondering about the timing of the first time an option gets cloned when the end user hasn't made a choice yet.

We can update the contents of <selectedoption> when it is inserted into the document. Does that answer your question?

[annevk]

Thanks! Right, microtask timing might be preferable to avoid cloning too often. As for your last point, <selectedoption> is inserted before any of <option> elements, so that does not address my question. But I guess we need to watch for mutations to those <option> elements, so maybe that would fall out automatically.

[josepharhar]

Thanks! Right, microtask timing might be preferable to avoid cloning too often. As for your last point, <selectedoption> is inserted before any of <option> elements, so that does not address my question. But I guess we need to watch for mutations to those <option> elements, so maybe that would fall out automatically.

When the <option> element is inserted, the <selectedoption> will be updated to match the new <option> if the new option considered to be the selected option by the <select>. Any time that the <select> thinks that the currently selected option is changed, then it will update the contents of <selectedoption>, and <option> insertion falls into that category.

[annevk]

One additional thought here: once we do <select multiple> will we regret aspects of this API?

I guess in particular if we do <select multiple> and also add a feature HTML arguably doesn't have (but some implementations do) whereby you don't render the control fully inline but still have a dropdown. (Because in the "normal" <select multiple> case there's no <button> presumably.)