Clone into all descendant selectedcontent elements by josepharhar · Pull Request #12263 · whatwg/html

josepharhar · 2026-03-16T02:23:25Z

This PR changes several things:

Instead of the first selectedcontent element in DOM order staying up to date, now all descendant selectedcontent elements of the select element will be kept up to date.
Rewrites the selectedness setting algorithm to prevent setting selectedness of options which haven't had their insertion steps run yet in order to match implementations and to update selectedcontent elements.
Creates a list of selectedcontent elements to update before doing actual DOM operations.

Fixes #12096
Fixes #11880
Fixes #11883
Fixes #11825

At least two implementers are interested (and none opposed):
- Chromium
- …
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
- Chromium: Already implemented
- Gecko: …
- WebKit: …
Corresponding HTML AAM & ARIA in HTML issues & PRs: not needed
MDN issue is filed: not needed because the existing mdn article doesn't mention anything about having multiple selectedcontent elements inside a select
The top of this comment includes a clear commit message to use.

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

This PR improves the "clear a select's non-primary selectedcontent elements" algorithm by making it create a list of selectedcontent elements to modify separately from modifying them in order to prevent the list of elements to change while iterating. Fixes whatwg#11880

This PR makes sure that the contents of the selectedcontent element stay up to date when the selected option is changed in the selectedness setting algorithm. This issue was found here: web-platform-tests/wpt#55849 (comment)

In order to make the selectedness setting algorithm match implementations, this PR makes the selectedness setting algorithm avoid changing the selectedness of option elements which haven't ran their insertion steps yet by checking whether the options have their cached nearest ancestor select element assigned yet or not. This was discussed here: whatwg#11825

…electedcontentredo

…edcontentredo

…contentredo Merged the PRs, now I need to do the selectedcontent rewrite to clone into all descendant selectedcontent elements.

annevk

Thanks @josepharhar! Here's some minor editorial feedback to start. Will try to verify these changes by implementing them.

annevk · 2026-03-25T09:40:38Z

source

+   <li><p>Let <var>descendantSelectedcontents</var> be « ».</p></li>

-   <li><p>Let <var>option</var> be the first <code>option</code> in <var>select</var>'s <span
-   data-x="concept-select-option-list">list of options</span> whose <span
-   data-x="concept-option-selectedness">selectedness</span> is true, if any such <code>option</code>
-   exists, otherwise null.</p></li>
+   <li>
+    <p>For each <var>descendant</var> of <var>select</var>'s <span
+    data-x="descendant">descendants</span>:</p>

-   <li><p>If <var>option</var> is null, then run <span>clear a <code>selectedcontent</code></span>
-   given <var>selectedcontent</var>.</p></li>
+    <ol>
+     <li><p>If <var>descendant</var> is a <code>selectedcontent</code> element, then <span
+     data-x="list append">append</span> <var>descendant</var> to
+     <var>descendantSelectedcontents</var>.</p></li>
+    </ol>
+   </li>


We don't need a loop for this. We can state this declaratively:

Let selectedContents be select's descendants that are selectedcontent elements, in tree order.

Also, I have a more substantive question here. Why doesn't this skip disabled selectedcontent elements immediately?

I think the selectedcontent-nested.html test currently expects this, but it seems wasteful and best avoided.

We don't need a loop for this. We can state this declaratively:

Done, thanks

Also, I have a more substantive question here. Why doesn't this skip disabled selectedcontent elements immediately?

Disabled selectedcontents will be skipped deeper in the algorithms called by this one - "clone an option into a selectedcontent" and "clear a selectedcontent" both check if the selectedcontent is disabled before modifying the DOM, and return early.

We could add a step to skip disabled selectedcontents here, but it would functionally be redundant, unless I'm misreading something. What do you think? Can we leave it as-is?

Can you explain https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/the-select-element/customizable-select/selectedcontent-nested.html then? Isn't parentSelectedcontent disabled once it is inserted?

Ok, yes I see how it would change the behavior to check if the selectedcontent elements are disabled before adding them to the list. I'll change the spec here and update the WPT.

source

This changes the behavior when selecting a new option in the case that there are nested selectedcontent elements inside the select. Before, the disabled selectedcontent would get cloned, but now it won't. Context: whatwg/html#12263 (comment) Bug: 458113204 Change-Id: I9afd550f21787b7daefb48c5a76712b5899e5b42

This changes the behavior when selecting a new option in the case that there are nested selectedcontent elements inside the select. Before, the disabled selectedcontent would get cloned, but now it won't. Context: whatwg/html#12263 (comment) Bug: 458113204 Change-Id: I9afd550f21787b7daefb48c5a76712b5899e5b42 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7737623 Reviewed-by: David Grogan <dgrogan@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1611875}

source

josepharhar · 2026-04-11T00:24:54Z

I updated this PR to avoid updating the selectedcontent element in the insertion or removal steps of the option element as per this discussion: #12096 (comment)

jnjaeschke · 2026-04-13T15:32:06Z

It seems that the post-connection steps are sync, while the removing steps queue a microtask. I think it would be more consistent if both were queueing a microtask?

Also -- I think that reset would now also run script because it clones into selectedcontent, which I think it shouldn't (at least in Gecko it is marked as not script running). Should we also queue a microtask here?

josepharhar · 2026-04-13T18:00:46Z

It seems that the post-connection steps are sync, while the removing steps queue a microtask. I think it would be more consistent if both were queueing a microtask?

Yes it would be more consistent that way, but since the selectedcontent element was designed to be as synchronous as possible I figured that this was a good way to keep it synchronous more of the time. I also think that inserting an option which become selected is more common than removing the currently selected option. If others think that both should do a microtask, I'm ok with that.

Also -- I think that reset would now also run script because it clones into selectedcontent, which I think it shouldn't (at least in Gecko it is marked as not script running). Should we also queue a microtask here?

Yes, reset causes cloning into selectedcontent. Why should reset not be script running?

josepharhar added 15 commits November 4, 2025 13:02

Update selectedcontent in selectedness setting

5d4835a

This PR makes sure that the contents of the selectedcontent element stay up to date when the selected option is changed in the selectedness setting algorithm. This issue was found here: web-platform-tests/wpt#55849 (comment)

remove duplicate li

dd2258a

inline one step list

85ef15c

change variable names

80e0785

nits

dfec190

Merge branch 'main' into selectednesssetting

6b749d8

readability improvements

af049b7

rename variable

a51df08

Merge remote-tracking branch 'origin/selectedcontentiterating' into s…

8f410a4

…electedcontentredo

Merge remote-tracking branch 'origin/selectednesssetting' into select…

12e587c

…edcontentredo

Merge remote-tracking branch 'origin/selectednesscheck' into selected…

ff783fa

…contentredo Merged the PRs, now I need to do the selectedcontent rewrite to clone into all descendant selectedcontent elements.

Update all descendant selectedcontent elements

96c2613

re-merge selectedness setting algorithm

4b75042

This was referenced Mar 16, 2026

Build list of selectedcontent elements to clear #11891

Closed

selectedcontent removing steps vs pagehide (and unload) #12096

Open

Update selectedcontent in selectedness setting #11890

Closed

Use cached select in selectedness setting algorithm #12083

Closed

annevk reviewed Mar 25, 2026

View reviewed changes

josepharhar added 5 commits March 31, 2026 14:25

inline loop

175b54c

in->of

5088085

,->;

a09e79c

Merge branch 'main' into selectedcontentredo

dae7e55

build list with only enabled selectedcontents

d095eb6

chromium-wpt-export-bot mentioned this pull request Apr 8, 2026

Check disabled when building selectedcontent list web-platform-tests/wpt#59059

Merged

jnjaeschke reviewed Apr 10, 2026

View reviewed changes

source Outdated Show resolved Hide resolved

josepharhar added 2 commits April 10, 2026 17:15

dont update selectedcontent in option insertion/removal steps

091d737

add missing display size check

86b46b3

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clone into all descendant selectedcontent elements#12263

Clone into all descendant selectedcontent elements#12263
josepharhar wants to merge 22 commits intowhatwg:mainfrom
josepharhar:selectedcontentredo

josepharhar commented Mar 16, 2026 •

edited by pr-preview bot

Loading

Uh oh!

annevk left a comment

Uh oh!

annevk Mar 25, 2026

Uh oh!

annevk Mar 25, 2026

Uh oh!

josepharhar Mar 31, 2026

Uh oh!

annevk Apr 7, 2026

Uh oh!

josepharhar Apr 7, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josepharhar commented Apr 11, 2026

Uh oh!

jnjaeschke commented Apr 13, 2026 •

edited

Loading

Uh oh!

josepharhar commented Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Conversation

josepharhar commented Mar 16, 2026 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

annevk left a comment

Choose a reason for hiding this comment

Uh oh!

annevk Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

annevk Mar 25, 2026

Choose a reason for hiding this comment

Uh oh!

josepharhar Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

annevk Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

josepharhar Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josepharhar commented Apr 11, 2026

Uh oh!

jnjaeschke commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

josepharhar commented Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

josepharhar commented Mar 16, 2026 •

edited by pr-preview bot

Loading

jnjaeschke commented Apr 13, 2026 •

edited

Loading