5 ms·
I think it should be Option 2, "Automatically reset the content when anything in the selected <option> changes." But furthermore, I think it should be possible
by dfabulich 2y ago
I think it should be Option 2, "Automatically reset the content when anything in the selected <option> changes."
But furthermore, I think it should be possible to turn <selectedoption> mirroring entirely off, e.g. with an attribute like <selectedoption mirroring="none">, and I think most developers using reactive frameworks should prefer to do that.
If I'm using any reactive framework designed to do targeted DOM updates, I want my framework to be in complete control. When an option is selected, I'll populate <selectedoption> myself. When an <option> is modified, I modified it, and I know which <option> is selected, so I'll perform a targeted DOM update of <selectedoption> as well.
You had a whole separate podcast episode about how/why having the browser itself do targeted DOM updates is an enormous can of worms, mostly for attribute vs. property reasons. https://offthemainthread.tech/episode/putting-react-in-the-browser/ https://offthemainthread.tech/episode/putting-react-in-the-b... And anyway, every framework wants to handle mutations differently, and framework designers are in consensus that we haven't picked a clear winner yet. So, as nice as it would be if we had a replaceHTML API that everybody loved, we don't have that now, and we shouldn't hold up customizable <select> for this.
<selectedoption> mirroring is for folks who don't want to use any JavaScript (and I think that's a good thing). In that case, mirroring all updates automatically, synchronously, is the simplest thing that can possibly work.
Developers who want optimal performance want full control, and they just want to turn mirroring entirely off.
- jaffathecake 2y agoThanks for the feedback! Fwiw, there's no point populating <selectedoption> yourself. Just don't use <selectedoption>. It's optional. That's probably what I'd do in most cases where I'm using a framework.
- dfabulich 2y agoGood to know. Say, is there a bug in Chrome Canary 132? When I opt into customizable <select>, "change" events stop firing. <style> select, ::picker(select) { appearance: base-select; } </style> <select> <option value="one">one</option> <option value="two">two</option> <option value="three">three</option> </select> <script> document.querySelector('select').addEventListener('change', e => { console.log(e); }) </script> And another. When I add <selectedoption>, I get a warning in the console, "A descendant of a <select> does not follow the content model. <selectedoption> one </selectedoption> " <style> select, ::picker(select) { appearance: base-select; } </style> <select> <button><selectedoption></selectedoption></button> <option value="one">one</option> <option value="two">two</option> <option value="three">three</option> </select>
- jaffathecake 2y agoThose sound like bugs but I'm not really familiar with the implementation. I haven't played with it much either. I'm just an outsider interested in the feature design.