Re: [csswg-drafts] How to implement and shape API for `<selectedoption>` element for `<select>` (#10242)

The CSS Working Group just discussed ``How to implement and shape API for `<selectedoption>` element for `<select>` ``, and agreed to the following:

* `RESOLVED: move forward with the light dom cloning api shape and discuss timing in the issue`

<details><summary>The full IRC log of that discussion</summary>
&lt;gregwhitworth> jarhar: there was a CSS issue where we briefly discussed this and the usecase is that if you are making a customizable select element you want to have a button that is fully styleable and contains rich content within the button and style it differently than the content that is in the option<br>
&lt;gregwhitworth> jarhar: if you have a country picker and the option only has the flag representation but in the selectedtoption shows the other DOM content within it. When the option is changed the contents of the option itself will be changed with the selected option's DOM content<br>
&lt;gregwhitworth> jarhar: the way I've implemented this in the Chromium POC is to use the cloneNode API and it works pretty well<br>
&lt;gregwhitworth> jarhar: in the past we've discussed using a useragent shadow and the sanitizer API<br>
&lt;gregwhitworth> jarhar: this would require us to complete the sanitizer API and a new CSS syntax<br>
&lt;jarhar> q?<br>
&lt;emilio> q+<br>
&lt;smaug> q+<br>
&lt;dandclark> q+<br>
&lt;gregwhitworth> emilio: what is the behavior if you don't have &lt;selectedoption> element<br>
&lt;astearns> ack emilio<br>
&lt;gregwhitworth> jarhar: if you don't provide a button at all then you'll get the same behavior you get today where the text content is copied into the button. If you provide the button without the selectedoption element then it won't be copied<br>
&lt;masonf> q+<br>
&lt;gregwhitworth> emilio: my only concern was if you were going to change the shadow DOM. It feels kind of clunky to change the Light DOM and all of its benefits but I don't have a better proposal<br>
&lt;astearns> ack smaug<br>
&lt;gregwhitworth> smaug: I think the light DOM option might be fine. This is similar to SVG use<br>
&lt;gregwhitworth> smaug: in Gecko it re-clones when we do style flush so you kind of want something like that here and since Anne was asking about scheduling<br>
&lt;gregwhitworth> emilio: do we want to handle dynamic mutations to the selectedoption<br>
&lt;gregwhitworth> jarhar: we want to keep up with any mutations on the element itself which Chromium uses today<br>
&lt;gregwhitworth> jarhar: the mutation observer will catch the mutation and clone the content into the shadowRoot of the button<br>
&lt;gregwhitworth> emilio: the key tricky bit is when this should run<br>
&lt;gregwhitworth> emilio: it should be similar to mutation and changeEvent case<br>
&lt;gregwhitworth> emilio: if we use mutation observer timing<br>
&lt;masonf> q-<br>
&lt;gregwhitworth> smaug: it would be odd that it wouldn't get the correct layout information<br>
&lt;gregwhitworth> emilio: in Gecko we have internal mutation observers that happens synchronously<br>
&lt;gregwhitworth> smaug: whenever layout is flushed we do the actual clone<br>
&lt;gregwhitworth> emilio: it is odd to do DOM observable changes at style flush time<br>
&lt;gregwhitworth> emilio: I don't think that would be a viable option here<br>
&lt;gregwhitworth> smaug: if you're updating Light DOM all of the other observers will still work so they should work as expected<br>
&lt;gregwhitworth> emilio: if you modify the option and read back the bounding client rect you should have the same issue<br>
&lt;gregwhitworth> q?<br>
&lt;masonf> q+<br>
&lt;gregwhitworth> chrishtr: if someone were to polyfill this with mutation observers they would get the experience?<br>
&lt;gregwhitworth> emilio: in jarhar example you grow the size of the icon or something upon cloning and you get bounding rect on the element you would need to wait for the post microtask<br>
&lt;gregwhitworth> astearns: do we need to have more discussions about timing in the issue or can we resolve it?<br>
&lt;masonf> q-<br>
&lt;gregwhitworth> emilio: I think we should discuss it async as there are tradeoffs<br>
&lt;gregwhitworth> chrishtr: is it ok to conclude that the approach we're taking is ok but we need to resolve on the timing?<br>
&lt;gregwhitworth> emilio: I suppose so, but if the timing is not right then it may make it so then it may require us re-thinking the light DOM cloning<br>
&lt;gregwhitworth> chrishtr: what considerations would make it "not fine"?<br>
&lt;gregwhitworth> smaug: in theory we could use custom element reaction timing which is sooner. We have options but haven't gone over them<br>
&lt;gregwhitworth> astearns: let's set timing aside for a minute<br>
&lt;astearns> ack dandclark<br>
&lt;gregwhitworth> dandclark: I added myself to the queue to support the light DOM solution since it's all author controlled content<br>
&lt;gregwhitworth> dandclark: I would like to be able to explain the timing with author defined APIs and it will be easier to understand<br>
&lt;gregwhitworth> dandclark: we can discuss that more in the issued<br>
&lt;chrishtr> +1 to microtask timing<br>
&lt;gregwhitworth> emilio: custom element timing seems worth exploring and would make things more consistent<br>
&lt;dbaron> s/custom element/custom element reaction/<br>
&lt;gregwhitworth> emilio: it is an issue beyond layout but any type of DOM interrogation<br>
&lt;gregwhitworth> astearns: we can resolve that we want to move forward with this shape but discuss the timing more<br>
&lt;gregwhitworth> astearns: any other concerns?<br>
&lt;emilio> +1 to light dom if there is a reasonable timing for it<br>
&lt;jarhar> proposed resolution: move forward with the light dom cloning api shape and discuss timing in the issue<br>
&lt;masonf> +1<br>
&lt;gregwhitworth> +1<br>
&lt;jarhar> RESOLVED: move forward with the light dom cloning api shape and discuss timing in the issue<br>
&lt;gregwhitworth> smaug: Anne was asking about the solution for multiple<br>
&lt;gregwhitworth> astearns: and maybe a seperate issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10242#issuecomment-2250667040 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 25 July 2024 15:23:27 UTC