select: Should `<selectedoption>` respond to mutations in the selected `<option>`

[josepharhar]

Consider the following:

<selectlist>
  <button>
    <selectedoption></selectedoption>
  </button>
  <option>foo</option>
</selectlist>
<script>
requestAnimationFrame(() => {
  document.querySelector('option').textContent = 'bar';
});
</script>

Should the <selectedoption>'s contents set to "bar", or should it stay as "foo"?
The equivalent use case for <select> will change the button's text to "bar".

@argyleink @mfreed7

We should probably wait for #571 to be resolved before getting this 100% figured out.

[argyleink]

i vote for the value to update to bar

[lukewarlow]

It should display whatever the form submitted value would be imo. So if that code would update the value (I think it would) then it should also update the displayed html

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

Yeah we should probably listen to mutations, it really seems like the sane default. It will likely be expensive for the browser to do that, but there are ways that we can improve the performance: https://chromium-review.googlesource.com/c/chromium/src/+/5370555/2/third_party/blink/renderer/core/html/forms/html_selected_option_element.h

[josepharhar]

I propose that we resolve to make the selectedoption element respond to mutations inside option elements. Otherwise, we might not pick up updates that authors have made to the DOM and it will leave the selectedoption element in a broken state.

[css-meeting-bot]

The Open UI Community Group just discussed selectlist: Should `<selectedoption>` respond to mutations in the selected `<option>` , and agreed to the following:

• RESOLVED: The selectedoption element should update its contents when the selected options DOM descendants are modified

The full IRC log of that discussion

<brecht_dr> jarhar From the browser engineer perspective this is an interesting one
<gregwhitworth> q+
<dandclark> q+
<bkardell_> q+
<masonf> q+
<brecht_dr> jarhar If you append some text in the option it would also show up in the button. is this something we should do. I think authors want to do that.
<Luke> +1
<brecht_dr> jarhar I would think we want to support that
<brecht_dr> gregwhitworth I agree we should. We did resolve on the inverse that the content is the innertext that is migrated.
<brecht_dr> gregwhitworth we should point that out in our documentation
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack dandclark
<brecht_dr> dandclark I agree with jarhar.
<gregwhitworth> ack bkardell_
<brecht_dr> bkardell_ I was curious. What is the case for somebody to do this?
<Luke> q+
<brecht_dr> jarhar Let's say you have some website where it has hydration kind of thing and your initial html you have a select element and then you have a seperate call in a database where you want to update your select options for example some imates
<brecht_dr> jarhar and you want to update that button as well by updating (hydrating) the options
<gregwhitworth> ack masonf
<brecht_dr> masonf I do have a fear about specifying this behaviour.
<gregwhitworth> q+
<keithamus> q+
<gregwhitworth> ack Luke
<brecht_dr> masonf I'm still wondering about real use cases
<brecht_dr> Luke How does a lazy loaded image cloned into the new area work?
<brecht_dr> masonf That should be ok? as it's loaded by its src link
<gregwhitworth> ack dbaron
<brecht_dr> masonf this seems more like a rendering question instead of cloning question
<brecht_dr> dbaron I find the hydration example to be convincing
<scotto9> q+
<masonf> q+
<brecht_dr> gregwhitworth The root scenario in the issue is the most common use case that I would expect. I'd expect that to work
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack keithamus
<scotto9> q-
<brecht_dr> keithamus If I were make this as a web component, I would make the selected option a slot. and do manual slot assignment
<dbaron> s/to be convincing/to be convincing, particularly for whatever is selected on initial page load/
<bkardell_> it does seem very similar
<brecht_dr> keithamus I'm sure the implementation is different, but I wonder why we shouldn't do it, because I would do it like this as a web component
<bkardell_> I think if you find the <mirror> proposal/ideas it used a similar argument
<gregwhitworth> +1 to bkardell_
<brecht_dr> masonf You'd actually have to clone, it should be in both places
<gregwhitworth> q?
<brecht_dr> masonf It needs to be cloned as you might want to style it differntly
<brecht_dr> gregwhitworth The same goes for accessibility reasons
<gregwhitworth> q?
<gregwhitworth> ack masonf
<jarhar> Proposed resolution: The selectedoption element should update its contents when the selected options DOM descendants are modified
<brecht_dr> una There is a gmail example where there is an icon int he button and additional text in the dropdown when opening
<Luke> +1
<dandclark> +1
<keithamus> +1
<masonf> +1
<brecht_dr> +1
<jarhar> RESOLVED: The selectedoption element should update its contents when the selected options DOM descendants are modified
<scotto9> caveat - if you are dynamically updating the selected option with a counter/countdown - please stop
<scotto9> stop coding in general
<scotto9> :)