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) ?