Thanks for looking at this. The reason that there are two separate mutations in chromium is because when the third option, <option selected> is parsed and inserted, it gets cloned into <selectedcontent> two times:

1. During the option element insertion steps, before the parser has appended children to the option element, because the option is selected. This results in a mutation which just removes all nodes from the selectedcontent element because the option element is empty.
2. When the option element is done parsing its children because it is selected.

This doesn't match the spec because the option element insertion steps just say to run the selectedness setting algorithm which doesn't clone anything into the selectedcontent element, but I'm not sure if that really is good behavior.

Consider the following:

<select id=select>
  <button>
    <selectedcontent></selectedcontent>
  </button>
  <option>one</option>
</select>
<script>
  const option = document.createElement('option');
  option.setAttribute('selected', '');
  option.textContent = 'two';
  select.appendChild(option);
</script>

I think that the selectedcontent element definitely needs to be updated for the newly selected option in this case, which can only be done through the option element insertion steps, right?

I think this was an oversight when I wrote this part of the spec, unless I'm missing something. I think it would probably be best to update the selectedcontent element in the selectedness setting algorithm, what do you think?

My prototype handles that as part of "finishParsingChildren". I don't really care strongly what we do I suppose, but I do get the feeling we lack a lot of test coverage (what if your example was created imperatively for instance) as there's only a minimal set of tests for this new element. And also that the specification is somewhat incomplete.

(I spotted Chromium setting <selectedelement>'s disabled to false upon removal, but there's nothing that tests for this, even though you might be able to. Although that also depends on whether or not we start guarding everything with "is connected" checks.)

Thanks, I am rewriting the test here and will take a closer look at the spec and chromium implementation here.

This PR should fix the selectedness setting issue: whatwg/html#11890

@josepharhar after spending quite a lot of time debugging the new tests here I'm still seeing different results from you and when I look at the Chromium code I think I understand why. Chromium has very different insertion and removal logic for selectedcontent elements from that what is standardized. I'm not sure Chromium behavior is desirable as it mostly results in different results for authoring error scenarios.

I also find the arrays this test outputs incredibly hard to debug. Claude AI has been helpful, but that really shouldn't be necessary. Not sure I have great suggestions there though, but maybe some guidance as to what is going on would have helped.

I'm going to update this PR with what I think the test should look like. This will require one further change to the standard for the removal case. I've added an early return there for selectedcontent elements that are disabled. Not much use in doing work for them.

Chromium has very different insertion and removal logic for selectedcontent elements from that what is standardized.

This is expected until this patch finishes getting reviewed and merged: https://chromium-review.googlesource.com/c/chromium/src/+/7127725

I also find the arrays this test outputs incredibly hard to debug. Claude AI has been helpful, but that really shouldn't be necessary. Not sure I have great suggestions there though, but maybe some guidance as to what is going on would have helped.

Agreed, when working on it locally I added console logging to be able to easily rebaseline the test, but such console logs result in lint errors (even when they are commented out if i remember correctly). I could have made a simpler test, but after hearing you say that we are lacking test coverage, I wanted to make sure that I was comprehensively testing many scenarios.