IMO, this whole cloning idea is overcomplicated. Let the duplication of markup happen server side or in React (or whatever).

If the developer wants a <selectedoption>, they should fill it with <option> elements that correspond to the <option> elements that appear in the dropdown. Each option could reuse the <label for=""> pattern to associate them with their counterpart.

Then, when an option is selected by the end user, the corresponding option inside the <selectedoption> would get a `selected` attribute.

The default CSS would be:

selectedoption > option { display: none; } selectedoption > option[selected] { display: block; }

This gives complete control to the developer, works fine without JS, and wouldn't have shocking side effects.

As they say, "duplication is cheaper than the wrong abstraction".

Correct if I'm wrong, but this still doesn't allow us to define the dropdown content and selected content for each option separately? Maybe something like this:

    <select name="commenters">
        <option value="annevk">Anne van Kesteren</option>
        <option value="jakearchibald">
            <label>Jake Archibald</label>
            <selectedcontent>
                <div>
                    <img src="profile.avif" alt="Jake's photo">
                    <div>Jake Archibald<br><small>@jakearchibald</small></div>
                </div>
            </selectedcontent>
        </option>
        <option value="sorvell">Steve Orvell</option>
    </select>

The value attribute would be required when using these new sub elements. This structure feels familiar and progressive to me.

Naively, I would imagine that the following JavaScript would cause 1 DOM update, 1 redraw of the option if the dropdown is open, and 1 redraw of the selected option:

    document.querySelector('option:selected selectedcontent').innerHTML = 'Jake Archibald';

Obviously, things are different when using multiple. Maybe a `select > selectedcontent` element containing a copy of each `option > selectedcontent` element that is updated on change events.

    <option>
      <div class="option-content">…</div>
      <div class="selectedoption-content">…</div>
    </option>

    option .selectedoption-content { display: none }
    selectedoption .option-content { display: none }

Why should styling even have a separate element? And duplicated? I thought the whole point of CSS was to not clutter HTML with styling.

This shouldn't be a literal new element. It should be a psuedo-element like other component parts like `::-[engine]-slider-thumb` are. You can then style `select::selected-option` and not have to mangle your HTML or worry about mirroring HTML.

I think it is worthwhile to revisit the starting motivation of customizing `<select>`. There would be generally two camps:

1. Declarative camp, where people expect two differently stylable copies of `<option>` somewhere in `<select>`. I don't think the exact copying mechanism and timing is very important here, as long as it can be safely done and works without JS.

2. Programmable camp, where people want the full control over appearance and behavior. We can reasonably assume that JS is required for this camp, and they generally have better understanding of what gets rendered or not in the first place.

Given both requirements, it seems wise to couple the clone timing with the event processing, which most cases in the second camp would have to do anyway. In the other words, the `input` event would have the default behavior of full cloning, and that default behavior should be prevented via `e.preventDefault()`. The second camp will almost always use this option and can use their own `MutationObserver` or similar to implement edge cases described in the OP. The timing and extent for the default behavior can be then optimized without affecting the second camp. It is even possible to distinguish two camps via different values of the `appearance` CSS property.

Sidetrack: It seems that `<selectedoption>` indeed exists mainly to distinguish two camps? But that leaves many edge cases like multiple `<selectedoption>` elements I believe. Maybe something like `<select reflect="foo"><button><option id="foo">...</option></button>...</select>` might be more appropriate. (`<output>` was my initial thought, but `<option>` would be more regular since it can't nest.)