| 00:14 | <jarhar> | i dont think we have usecounters for that particular case |
| 00:15 | <jarhar> | the new select would be a regular element which gets popover behavior, so it wouldnt escape outside its frame |
| 00:16 | <smaug> | right |
| 00:20 | <smaug> | jarhar: does the parser allow all the possible elements inside <option> ? |
| 00:21 | <smaug> | oh, that would be approach 3 |
| 00:22 | <jarhar> | my proposal would allow everything in option |
| 00:23 | <smaug> | jarhar: hmm, what is the difference between 2 and 3 then? 2 requires use of datalist but 3 wouldn't since one could just use anything inside option? |
| 00:27 | <jarhar> | option 2 doesnt relax the parser at all except within button and datalist tags. so the following would be parsed in option 3, but option 2 would continue to throw away the div: |
| 00:27 | <jarhar> | ah the html i wrote is gone |
| 00:27 | <jarhar> | select option div text node |
| 00:28 | <jarhar> | option 2 would do what the parser currently does here and turn it into this |
| 00:28 | <jarhar> | select option text node |
| 00:28 | <jarhar> | to get the div in option 2 you have to wrap the option in a datalist, which also acts as the popover element |
| 00:30 | <smaug> | and still one more question today - before it is getting too late for me. If one doesn't use <button> inside <select>, what is the expected behavior? Browser would effectively have button as part of internal shadow DOM and that button has then <selectedoption> ? |
| 00:31 | <jarhar> | yes, but in my current implementation we just copy the text content from the selected option rather than having a full on selectedoption element so we dont have unsanitized content in the ua shadowroot |
| 00:31 | <jarhar> | option 2 is implemented in chrome behind experimental web platform features if you want to try it out |
| 00:32 | <jarhar> | you just have to add appearance:base-select to the select element to make it render the new stuff |
| 00:32 | <smaug> | oh, text content. That is something what was unclear in the explainer, since in one place it is talking about text content and in other place cloning |
| 00:33 | <smaug> | "<selectedoption> - The element which contains the text of the currently selected option. Every time that the user selects an option, the browser will replace the text content of this element with the text content of the selected option." |
| 00:33 | <smaug> | "The <selectedoption> element enables developers to declaratively clone the content of the selected <option> element to the button and to style it distinctly from the <option>" |
| 00:34 | <jarhar> | ah thanks for pointing that out ill fix it right away |
| 00:35 | <jarhar> | when the author used the selectedoption element, it clones the node not just the text content |
| 00:35 | <jarhar> | *uses |
| 00:36 | <smaug> | ok, and that is the reason why https://open-ui.org/components/selectlist/#rich-content-in-options has perhaps a bit surprising behavior. The image isn't part of the selected option. |
| 00:37 | <jarhar> | yeah thats because html content doesnt include the selectedoption element |
| 00:38 | <jarhar> | if we end up using the not yet implemented sanitizer api to check the content before replacing it, then we can put it in the ua shadowroot by default and youll get the "rich content" without replacing the button |
| 00:51 | <smaug> | https://open-ui.org/components/selectlist/#customizing-basic-styles something adds the arrow to the button, but it is not added in https://open-ui.org/components/selectlist/#rendering-the-option-differently-in-the-button |
| 05:22 | <annevk> | Jake Archibald: they use an opaque origin, but both them and sandboxed iframes won't defend you against Spectre attacks in current browser engines |
| 15:01 | <jarhar> | thanks, i fixed it by removing the button tag from the example which has a down arrow. the down arrow is inside the button element in the UA shadowroot, so you don't get it when you provide your own button tag. |