Define the <selectedcontent> element

[josepharhar]

The <selectedcontent> element is part of the customizable <select> proposal: #9799

It allows authors to declaratively clone the contents of the currently selected <option> of a <select> and style it independently for use in a base appearance <select>'s button.

The timing of cloning has been discussed here:
#10520

The selectedcontent element has been discussed generally here: w3c/csswg-drafts#10242

html-aria PR: w3c/html-aria#528
html-aam PR: w3c/html-aam#566

• At least two implementers are interested (and none opposed):
  • Chrome
  • …
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/semantics/forms/the-select-element/customizable-select/selectedcontent.tentative.html
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/parsing.html ( diff )

[annevk]

It seems this is missing a lot of the boilerplate that new elements normally have as well as changes to content models, indexes, etc. See also this checklist at the top of source:

 !   Adding a new element involves editing the following sections:
 !    - section for the element itself
 !    - descriptions of the element's categories
 !    - images/content-venn.svg
 !    - syntax, if it's void or otherwise special
 !    - parser, if it's not phrasing-level
 !    - rendering
 !    - obsolete section
 !    - element, attribute, content model, and interface indices

[josepharhar]

Thanks!

• I added a dl with a bunch of metadata for the element itself.
• I didn't include this element in any categories
• I didn't update the content-venn image because I didn't add it to any categories.
• I didn't update syntax or parsing because it doesn't have any special rules and I didn't implement anything in the HTML parser for this.
• I didn't update rendering because I noticed that elements like <div> and <span> don't have sections in there, and selectedoption is supposed to render like those elements.
• I didn't update the obsolete section because nothing is becoming obsolete...?
• I updated the element and interface indexes

[annevk]

This still seems incomplete. Where does the button element indicate this element can be a descendant, for instance? If you don't adjust the categories, you still need to account for how the categories are used.

[josepharhar]

This still seems incomplete. Where does the button element indicate this element can be a descendant, for instance? If you don't adjust the categories, you still need to account for how the categories are used.

Thanks, I updated the content model of the button element

[josepharhar]

I just added a "disabled" concept to help prevent infinite loops during cloning due to putting a selectedcontent element inside multiple select elements, another selectedcontent element, or an option element.

[josepharhar]

I made the select.value and select.selectedIndex setters trigger cloning to follow this resolution: openui/open-ui#1119 (comment)

[dbaron]

A few comments from looking at parts of this:

[josepharhar]

In response to feedback from @dbaron, I made the one selectedcontent element which receives updates be the first one in tree order instead of the first one to be inserted. I also removed the select descendant selectedoption elements list.

[hsivonen]

Adding a proper backlink to: mozilla/standards-positions#1142

I'm worried about breaking the implied invariant that the parser creates exactly one element node per (possibly implied) non-erroneous start tag. I don't at this time have a concrete end-to-end scenario of what badness exactly may ensue, but it's a bad sign about breaking an invariant leading to issues that then need addressing that there's already a remark about preventing infinite loops upthread and a separate issue about the timing of cloning (#10520).

In the error handling case where one element per start tag does not hold, the spec says "Create an element for the token for which the element node was created, in the HTML namespace" instead of cloning a formatting element. This is in response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=6743 , which was motivated by avoidance of data flows from the live DOM into the tree builder algorithm. However, it looks like the option cloning as proposed could happen on the main thread in a way that does not affect the subsequent decisions of the tree builder algorithm.

Do I understand correctly that cloning into the regular DOM instead of a UA shadow DOM came from w3c/csswg-drafts#10242 (comment) ?

[josepharhar]

Do I understand correctly that cloning into the regular DOM instead of a UA shadow DOM came from w3c/csswg-drafts#10242 (comment) ?

Yes. We had many lengthy discussions about this, since cloning into shadow DOM avoids a few problems. But it also introduced a myriad of issues that were much more serious than the ones posed by cloning into regular DOM.

[domfarolino]

Is it just a straight-up equal comparison we want? Chromium seems to do some stuff with whitespace, do we need to do the same here?

[josepharhar]

The chromium code there which does stuff with whitespace is accounted for in the option's value here (option value uses option text in the spec): https://html.spec.whatwg.org/#dom-option-text

Assigning to select.value doesn't seem to do anything special with whitespace: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_select_element.cc;l=636-671;drc=fc2575ac635633b2972b49eec663250ac05a1a53

[domfarolino]

Ah OK got it. So I don't think anything is required here then. Can we resolve this?

[domfarolino]

But the "get a select's enabled selectedcontent" algorithm doesn't limit its search to the select element's first child button. Is this out of date?

[josepharhar]

You're right, I pretty much just said this because it is meant to be used inside the button. I removed this paragraph.

[domfarolino]

Great, this can be resolved right? (Just want to double check with you instead of resolving it myself)

[domfarolino]

Now that I think about it, do we actually have to call this? Are there any circumstances where this could actually throw an exception? The only one that stands out to me is if nodes contains a doctype, but I don't think that's even possible, right? How does the Chromium impl look here? Are there any known cases where we see an exception?

[josepharhar]

I copied this from here, do you know why it's needed there? https://dom.spec.whatwg.org/#dom-parentnode-replacechildren

We are also calling it within ReplaceChildren in chromium I think: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_selected_content_element.cc;l=35;drc=8c797f761029413678dc8d9c2308d78336046ab8

[domfarolino]

Yeah because an author can call $0.replaceChildren($0.parentNode) which would trip the second pre-insertion validity condition and throw an exception. I don't think we can run into that in our case, since we definitely aren't ever trying to insert parents into their children, right?

So the real question is about whether we need this call for the other pre-insertion conditions. I don't think we can ever trip those either though.

We are also calling it within ReplaceChildren in chromium I think: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_selected_content_element.cc;l=35;drc=8c797f761029413678dc8d9c2308d78336046ab8

OK this is great to see. Note that we're asserting no exception in the impl, meaning we're guaranteeing that all pre-insertion checks will pass, and never rseult in an error. So I think we can remove this from the spec.

[domfarolino]

So the Chromium implementation seems to unconditionally assign <var>nearestSelectAncestor</var> in this case, not limiting assignment to the non-null case. That seems to not matter in the implementation since the last two steps of this algorithm that actually use the nearest select ancestor don't appear the impl. What am I missing?

[josepharhar]

The difference here is that chromium's select elements still keep a list of descendant selectedcontent elements as a performance optimization which I removed from this PR earlier, and all ancestor selects get this selectedcontent element added to their list of descendants, even when there are nested select elements.

The implementation doesn't seem to correctly remove them in the corresponding HTMLSelectedContentElement::RemovedFrom, so I'm going to change the implementation to match the spec

[josepharhar]

https://chromium-review.googlesource.com/c/chromium/src/+/6196578

[domfarolino]

Cool! I think this can be resolved now then, right?