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 ofsource:

 !   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

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

This still seems incomplete. Where does thebutton 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.

This still seems incomplete. Where does thebutton 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

@domfarolino sorry, I missed your mention of me since I've already been mentioned in this thread, github doesn't make it clear when someone has been re-mentioned.

the html aam (2344) PR is waiting on this to merge. It hasn't had any updates since I made some wording changes to a note in February. There are various other HTML AAM PRs related to customizable select which are also ready to go once everything is ready to merge into the HTML spec.

the aria in html pr (528) is essentially ready to go as well. No more spec updates needed, just some issues to file against conformance checkers.

@josepharhar not sure if this is the PR to comment on or not, but per our chat discussion it's probably worth calling out that while<option label=foo> can be used with the customizable select, and will render a visible label for the option in the select's popup - if selected nothing will be returned to theselectedcontent element - since that works by cloning the descendants of the option, and in this care there are none.

Someone can still benefit from broader styling capabilitiesand still define option element label text using the attributeif their customized select does not contain a button part (and thus no selectedcontent element). Maybe it makes sense to call this out? that way, if someone does attempt to use label attributes when defining their options, it's made clear "if you want to do this, then you shouldn't use the button part/selectedconent elements. but, to have greater control, use child content of the option to define your labels, which will also allow for more styling capabilities for represented the selected content in the select's collapsed state.

or you know... word smith as you see fit

Thanks Scott! I added a note here:bcd9669

Permdn/content#39411; "Dynamic modifications to the selected<option> element's content made after the<select> element has been created are not automatically cloned to the<selectedcontent> element, and must be manually updated by the developer."

This has usability and security risks. If the option can be updated without the content of the<selectedcontent> updating along with it without JS, this has the likelihood of leading to broken forms. It's also a security risk as the user may submit a form with an unintended value that is not visible due to malicious code.

We don't want to add anything to the web platform that may potentially break things, make a form control less accessible, or add any vulnerabilities.

If the option can be updated without the content of the<selectedcontent> updating along with it without JS, this has the likelihood of leading to broken forms.

I don't think this is possible without JS. To get this behavior, youneed JS manipulating the DOM in a very particular way: the<option> contents must be mutated after that<option> is appended to the<select>. If the site is using plain html and css, then<selectedcontent> should "just work" in all cases.

It's also a security risk as the user may submit a form with an unintended value that is not visible due to malicious code.

If the malicious code has DOM access, isn't this already true?

<select id=purchase_quantity>  <option value=1000000> 1 </option></select>

This would submit the value "1000000" even though the user sees "1".

If the site is using plain html and css, then<selectedcontent> should "just work" in all cases.

If the site is using JS, will it ever break the<selectedcontent>? My understanding is that is can, and does.

<selectid=purchase_quantity><optionvalue=1000000> 1</option></select>

while the above is currently and has always been possible, if the following is ever possible, the implementation needs to be fixed:

<selectid=purchase_quantity><button><selectedcontent>1</selectedcontent></button><optionselected> 10</option></select>

This being pseudo-markup: Where "selected" is not necessarily an attribute, but rather the current state

This PR won't be merged and will instead be included in a bigger PR including all customizable select PRs:#10548

An element that modifies the page by adding/removing elements seems like a bad idea.

It will break any code that expects the structure of the html to be the same as it was served.