[select] Should the inner HTML & styles of the selected option be copied into selected-value?

[clarumedia]

Chrome 103.0.5060.114

When an option is "selected" using the "selected" attribute, shouldn't the style of that option supersede the style of the select ?
Use case: colours set on select options via CSS, the selected colour would display having been selected.

<select>
	<option style='color:blue;' >1 Blaa x</option>
	<option style='color:red;' selected >I would expect the collapsed select control to be red because this is the selected option</option>
	<option style='color:green;' >3 Blaa more</option>
</select>

[gregwhitworth]

@clarumedia this is a solid thought; however, this isn't specified as it relates to the base styling for <select> since that is left to the UAs and they're technically different elements. So while they often appear as one set of elements the options are actually not what's being rendered but what is being reflected. This is however one good thing of the new <selectmenu> that we're working on as you can now achieve this and also see how this anatomy exists in this pen: https://codepen.io/gregwhitworth/pen/XWEBLwe

Now you could argue that you'd like <selectmenu> to do this to appear as though it's truly reflecting the content within the option and that's worth considering although I can think of arguments for not doing this by default and leaving it for the author to do. Interested to get your thoughts as well as @dandclark. This is a usecase worth thinking about because options can now have arbitrary content/styles and I'm curious if common examples clone and reflect all content or just the value.

[clarumedia]

@gregwhitworth One thought is a CSS directive or attribute for the selectmenu tag that would tell it to incorporate the CSS of the selected child. Sort of reverse inheritance from the selected item. I can see this could potentially get messy if the child does things like expand horizontally or vertically (for example). Perhaps if we could specify which CSS attributes could effectively be "inherited" from the selected child back to the parent ? Something like:

select {
color: inherit-selected;
}

[css-meeting-bot]

The Open UI Community Group just discussed [select] Inconsistent CSS handling when the "selected" attribute has been set on an option ?.

The full IRC log of that discussion

<gregwhitworth> Topic: [select] Inconsistent CSS handling when the "selected" attribute has been set on an option ?
<gregwhitworth> github: https://github.com//issues/571
<hdv> gregwhitworth: this one was about the current select menu… a lot of this is about the contents of an option… should there be a default expectation of how much is reflected? should it include styles? or even all of the contents?
<tantek> could see both, e.g. icons/content and text/bg colors
<hdv> gregwhitworth: if I have a picker with a name and title below… I could have a CSS grid, but the value could just be my name… do we put the entire contents or just my name?
<hdv> gregwhitworth: I know there are use cases where people clone the entire element
<masonf> q+
<hdv> gregwhitworth: and you could do that today
<gregwhitworth> ack masonf
<hdv> gregwhitworth: wanted to hear people\;s thoughts on when reflection should occur
<hdv> masonf: I think we could do this with imperative slotting, if we added a slot to the anatomy of the default button, and assign the select option to that slot
<scotto_> q+
<hdv> masonf: that would get tricky but it would be doable
<gregwhitworth> ack scotto_
<tantek> do any existing UI frameworks support this kind of style hoisting behavior?
<hdv> scotto_: I think people people would the selected text reflect the value… I could see use cases where people would want to do something like that?
<hdv> scotto_: especially looking at how complex these options could get… so that button elements don't get put inside of the selected
<masonf> q+
<hdv> scotto_: allowing everything to be posted in the value of the combobox has some potential breaking issues to it
<gregwhitworth> q+
<gregwhitworth> ack masonf
<hdv> scotto_: even on a smaller scale, if someone selects a value and wants to style the combobox based on that selected value, that should definitely be allowed
<hdv> masonf: I agree what scotto_ says would be true… we would be able to do this by slotting in your own button… that alleviates the browser to make those kinds of decisions
<hdv> gregwhitworth: I don't think we need to solve this for V1
<hdv> gregwhitworth: [shares screen to show combobox in Outlook that shows contact suggestions in the 'To: ' field, where contacts have avatars]
<masonf> q+
<hdv> gregwhitworth: I think folks can solve this for themselves now in V1, but want to clarify if we could never fix this?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack masonf
<hdv> masonf: I think this is a V-forever question, it would not be possible to change while being backwards compatible
<tantek> q+ to ask if any web UI frameworks support this kind of feature
<gregwhitworth> ack tantek
<Zakim> tantek, you wanted to ask if any web UI frameworks support this kind of feature
<hdv> gregwhitworth: so the question is… and what we all should probably think about… would you bring up all the styles plus text content, or just the text content?
<scotto_> q+
<hdv> tantek: do any existing UI frameworks support this kind of option, to have a 'rich option' more than just plain text, be hoisted up to the selected option?
<hdv> tantek: that is usually a good indicator… if there is we should probably consider it, if not, it would be a steep hill to make the case for this
<una> q+
<gregwhitworth> ack scotto_
<hdv> scotto_: I saw some use cases kind of like that… the content is usually slotted into a different area, usually not the area where somebody actually types… it usually gets slotted somewhere adjacent
<gregwhitworth> q+
<hdv> scotto_: there are instances of something like this happen
<gregwhitworth> ack gregwhitworth
<hdv> una: I think this is more common than we think… in Google Docs and Notion for instance
<hdv> una: your email example reminded me of many examples I saw across the web
<tantek> q+ to agree with icon(img)+text example and maybe this is a pseudo-class use-case too?
<hdv> gregwhitworth: if everyone can please get some use cases in the thread… so that we can discuss if we should spend time on this up front or not
<hdv> gregwhitworth: please do take the time, the issue is linked in IRC
<hdv> gregwhitworth: next week I'll need somebody to chair if anyone is able to chair
<masonf> una: https://github.com//issues/571
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been emilio, masonf, miriam, hdv, una, scotto_, flackr, sana, sarah_h_, oluOnline, vicgutt, tantek, dbaron, bkardell_
<tantek> +1 una, agree with icon(img)+text example and maybe this is a pseudo-class use-case too
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/08/11-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye

[css-meeting-bot]

The Open UI Community Group just discussed [select] Inconsistent CSS handling when the "selected" attribute has been set on an option ? #571.

The full IRC log of that discussion

<hdv> topic: [select] Inconsistent CSS handling when the "selected" attribute has been set on an option ? #571
<hdv> github: https://github.com//issues/571
<hdv> JonathanNeal: this one has to do with the `selected` attribute and the style of the selected element being hoisted up
<hdv> JonathanNeal: is Chris on the call?
<hdv> dandclark: it looks in the issue the request was for more use cases
<hdv> dandclark: so looks like we should defer it from the agenda until we have that
<hdv> JonathanNeal: ok let's add it to the next agenda once it is ready
<hdv> dandclark: it's a fairly complex issue

[scottkellum]

Font selection may also be relevant here. This is from the Font Access API demo.

[css-meeting-bot]

The Open UI Community Group just discussed Should the inner HTML & styles of the selected option be copied into selected-value?.

The full IRC log of that discussion

<gregwhitworth> Topic: Should the inner HTML & styles of the selected option be copied into selected-value?
<gregwhitworth> github: https://github.com//issues/571
<hdv> gregwhitworth: technically we've already talked about this issue in the past … what happens today… when you invoke the popup in some form or fashion, give it some options, traverse them and pick an option, the value of that option is inserted both as the 'value' and as the innertext of the 'selected-value' part
<hdv> gregwhitworth: what the person opening the issue was talking about was just the colour, but it got us thinking about should we actually copy the whole computed content in rather than just the value
<hdv> gregwhitworth: so the value itself will remain the option value, but the rendered contents to the end user would become the contents of the option element
<masonf> q+
<hdv> gregwhitworth: this is useful when you have complex content inside of the content… like an avatar with a name, when you select it you might see it as an example
<AlexanderFutekov> q+
<dandclark> q+
<hdv> gregwhitworth: I've tried to find these, all of them converted to a string of text
<hdv> gregwhitworth: i wanted to raise this… I personally would like to resolve that the value itself will be used as the value, but we'll take the innerHTML of the <option> and use that as the HTML of the selected-value part
<gregwhitworth> ack masonf
<hdv> masonf: they have the ability to slot in whatever they want… you already gave some examples of when the selected-value has something slightly different
<hdv> masonf: this does seem risky
<gregwhitworth> ack AlexanderFutekov
<hdv> AlexanderFutekov: in the past I had this use case… I built a dynamic styleguide where you could pick backgrounds and colors, it built the classes to use in CMS… what I needed there was a dropdown that could do rich content
<hdv> AlexanderFutekov: just having a plain string of text cannot describe the visual complexity
<hdv> AlexanderFutekov: it is more complex than a color picker. but it's a use case I had to do
<gregwhitworth> ack dandclark
<hdv> dandclark: I think there are some pitfalls
<masonf> q+
<hdv> dandclark: if we take the innerHTML into the selected-value part, and our goal is also to have the background come along, it would depend on whether it was an inline style… or maybe via a stylesheet, and within that whether it was a class or something else
<hdv> dandclark: things like having an ID on an option would get fuzzy because that would get cloned into the selected-value part
<hdv> dandclark: that said, there are scenarios that would be useful
<hdv> dandclark: for instance if all options had a little icon in them and it would just work
<sarah_h> q+
<hdv> dandclark: having said that, I am a little afraid of this. also, if we do want something like this, should we deepclone the contents rather than spinning up the parser to serialise it out?
<gregwhitworth> ack masonf
<JonathanNeal> I have had a need for deep cloning content, as well.
<JonathanNeal> But not for selectmen.
<gregwhitworth> q+
<hdv> masonf: those are better examples… your ID example is great
<hdv> masonf: there is exactly that demo in the selectmenu demo that we did, a component where you can pick a color and the picked option would take that color… am curious how hard that was to do… if it was hard we should maybe offer something, if it was easy, maybe not
<gregwhitworth> ack sarah_h
<JonathanNeal> But I have needed this kind of cloning anytime I need to “reflect” some light provided value into multiple locations. I can watch changes to the DOM, but any CSSOM would indeed be lost.
<hdv> sarah_h: I had another example… if we have buttons inside of options and they get copied, that is also copied over and could cause issues
<AlexanderFutekov_> q+
<hdv> sarah_h: in my experience building these kinds of things… it is common to have a few things within your options that you _don't_ want to see in your trigger button, in fact I think that's actually more common than that you do want to add things in
<JonathanNeal> q+
<hdv> sarah_h: so I would say it would be better to optimise for the more common case of not cloning everything in… my vote would be to default to string value
<hdv> gregwhitworth: I'm not super concerned with the ID issue, because it would technically be using web components
<hdv> gregwhitworth: re: copying all the contents in but you don't want to see them all… it would be easy to select those in CSS and display none them, I probably will have classnames on them
<masonf> q+
<hdv> gregwhitworth: if it's the other way around, I would need to write JavaScript to actually get the contents in… so if content is copied, easy to hide, if it is not copied, hard to add in afterwards
<hdv> gregwhitworth: will take as an action item to look at the design systems we have listed, will also check out Gmail, Outlook, etc
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack AlexanderFutekov_
<masonf> q-
<hdv> masonf: I just checked, it is about 3 lines of JS in the selectmenu demo
<AlexanderFutekov_> https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-box-reflect and https://developer.mozilla.org/en-US/docs/Web/CSS/element
<hdv> AlexanderFutekov_: I remember that we might not actually need to clone the DOM, if we want to mirror the styles, I remember two cases, see links above
<sarah_h> q+
<hdv> AlexanderFutekov_: these are two ways where the styles reflect styles of another element in CSS
<hdv> AlexanderFutekov_: one none standard, the other is standard, seems browsers can implement this without copying
<hdv> masonf: I worked on this and it's not pretty
<dbaron> they're also laying out in a different area in many cases
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: we've been talking about content, innerHTML, which has to do with having access to the DOM of it… which is what I was going to comment on… but the issue itself is about styling… were we also discussing ability to access content?
<hdv> gregwhitworth: yes they originally hinted on styles, but then later on wanted to copy complex styles, that made me think what about elements
<hdv> gregwhitworth: so you're totally on topic
<hdv> JonathanNeal: I would separate these two topics… when we discuss having access to the content as far as the DOM nodes, that reminds me of what you would do with a form, grab elements by name and grab a label of an input… a useful utility to go and grab those things
<hdv> JonathanNeal: it seemed like that sort of issue
<hdv> JonathanNeal: that's different than, say, if we allow the content to be in there, when it is announced or read, there is accessibility issues
<hdv> JonathanNeal: and then there's this third thing of reflecting styles from another element. Three issues worth looking at, it might be easier to tackle them separately
<hdv> gregwhitworth: the value itself will always remain a string, so we're not talking about taking innerHTML and making that `element.value`
<hdv> gregwhitworth: what we're talking about is like… a country picker with a flag… effectively currently it does innerText, but if you wanted to see the flags, you would need to manually go in, find the images and then insert it… so I am talking about changing this and making a deepclone instead
<hdv> gregwhitworth: you shouldn't end up with accessbiility issues, if you have them you should have them in your original option already
<hdv> JonathanNeal: I had this exact issue when I was working on Web Components… working on components that expand, like in a tree, like when you expand it you can see the children, you end up with a duality
<hdv> JonathanNeal: even with tabs we ended up in a situation where we almost wanted to double slot things
<hdv> JonathanNeal: if the data binding is possible we could help a lot more use cases… basically take the styles from another element by reference… push its computedStyle to another element
<masonf> q?
<hdv> JonathanNeal: I feel this would be worth taking on and solve problems beyond selectmenu
<gregwhitworth> ack sarah_h
<hdv> sarah_h: one small thing… the accessibility consideration for copying the button isn't necessarily not an issue, because it would be in a different place in tab order which could be an issue
<hdv> sarah_h: I wonder if it would be worth looking at, if you want to put an image in front of text… and you want to do something like type to search, should it be part of that? is that going to break type to search… or should the author be able to define a separate string that gets used in those kinds of things?
<JonathanNeal> Brilliant, sarah_h. I totally forgot for a moment about the `value` attribute. Interesting idea, if you are suggesting we could somehow tag content as participating in the computed value.
<hdv> gregwhitworth: would encourage everyone to look at use cases around this… 
<JonathanNeal> Super loosely related. I remember Google did something a little bit similar to this with a `data-` attribute for marking things as participating in search.
<hdv> gregwhitworth: thanks everyone so much, watch Discord for next week's time, may be on a Wednesday
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been dandclark, scotto_, hdv, JonathanNeal, masonf, bkardell_
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/09/29-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye

[jonathantneal]

I believe this is a very related feature request.

whatwg/html#6507

And I have created a related proposal for this here:

#616

[smhigley]

I think it could be worth considering whether <option> elements need a prop to specify a string-only representation of the contents when selected, for a couple reasons:

• type-to-select depends on a string comparison of the effective value, not the potentially complex content within an option
• if/when we get an editable version of <selectmenu>, inputs do not support complex content, and I see benefit in having consistency across select-only vs. editable versions of selection components

[css-meeting-bot]

The Open UI Community Group just discussed [select] Should the inner HTML & styles of the selected option be copied into selected-value?.

The full IRC log of that discussion

<gregwhitworth> Topic: [select] Should the inner HTML & styles of the selected option be copied into selected-value?
<gregwhitworth> github: https://github.com//issues/571
<jhey> pi would make the attribute shorter!
<bkardell_> also looking forward to the punny critical titles like how they are half baked or something
<hdv> gregwhitworth: to provide context: original issue was: we only put the text value into the selected-value part in, we don't also copy style.
<hdv> gregwhitworth: from that we pivoted to… what if you want not just style but also the DOM that was in the selected value, so like when there's a name + avatar + email, those get copied too
<hdv> gregwhitworth: so I went in and looked… almost all of them are never the complex content and 1:1 copied it. Even the Gmail/Outlook clients… they do something like I described, but then just show the value or part of it, not the whole thing
<masonf> q?
<masonf> q+
<hdv> gregwhitworth: I'm not seeing where folks would desire the full contents and place it into the selected-value
<scotto_> q+
<sarah_h> q+
<hdv> gregwhitworth: I think now we effectively take the innertext and put it in. So my proposed resolution would be to keep it as is… and to sarah_h's point from last time, folks can still copy the contents manually and do it manually
<gregwhitworth> ack masonf
<hdv> masonf: generally I think I agree with you, that most use cases don't seem to want this, and it does seem to complicate things
<hdv> masonf: so basically just use the innerText with no styling
<hdv> masonf: however… there's this thing called mateiral symbols, and probably things like it elsewhere… you use a text and the system will use an icon instead… that kind of use case would be broken by this behavior
<hdv> masonf: a potential solution that we haven't talked about a lot yet is imperative slotting
<hdv> masonf: that way you could keep everything
<hdv> masonf: limitation is that they have to be direct children of the selectmenu
<gregwhitworth> ack scotto_
<hdv> masonf: this may be an easy way to fix this?
<gregwhitworth> q+
<hdv> scotto_: it does seem that what people need here is guidance on using the <template> element and making up the markup they want to return
<hdv> scotto_: if we're going to allow nested interactives inside of options, we don't want those nested interactions inside of the value
<hdv> scotto_: it's always some variant of it, not the exact subtree
<gregwhitworth> ack sarah_h
<jhey> q+
<hdv> sarah_h: I put this in a comment in the issue, but to repeat that: I think there are two considerations: 'type to select' incl jumping to the matching option… having an editable selectmenu that is not datalist and actually works, having a prop to define a string representation of the option separately from its contents
<hdv> sarah_h: and that that would be displayed as an option
<hdv> sarah_h: like for structured styled content
<hdv> sarah_h: usually it is a subset or specific part of the content
<hdv> sarah_h: if we have an editable version of this, we probably want parity on how it works
<hdv> sarah_h: we might want to have things like 'cannot handle images', stuff like that.
<hdv> gregwhitworth: it makes complete sense, but also complicates things a bit
<hdv> gregwhitworth: the slot thing is an interesting thought but would not be in favour of it
<hdv> gregwhitworth: eg the author needing to adjust what is set in there if they have complex DOM structure
<hdv> gregwhitworth: the examples I've seen in email clients… like avatar+name+title of the person, if you grab innerText of that, it would grab title and name and then folks will need to clean that up
<hdv> gregwhitworth: do we actually want a feature where we allow that? if they're searching do we want a schema of what they're searching through?
<tantek> q?
<gregwhitworth> ack jhey
<gregwhitworth> ack gregwhitworth
<hdv> jhey: what would end user want to achieve with this? like I have a select menu and I just want to drop icons with each options… and when I select that I want to see the flag
<hdv> jhey: the paint point is styling the select, it's not just the selectbox, it's the whole thing, and we want to make it as easy as we can for people
<tantek> +1 jhey
<tantek> q?
<tantek> q+
<hdv> gregwhitworth: that case is pretty much why it was opened up… and in that case you could grab the DOM and clone the stuff in
<hdv> gregwhitworth: if that is the default behaviour, you end up with a lot of stuff by default and reach for script to find the things you want
<hdv> gregwhitworth: you could just hide it with DOM structures
<hdv> jhey: would there be some sort of slotted version of this?
<hdv> gregwhitworth: this is also kind of where sarah_h was going
<hdv> gregwhitworth: basically we're defining data binding… also done that in IDL space, but this is the first time this kind of issue has been defined
<hdv> gregwhitworth: this could be used for a lot of things
<masonf> q?
<masonf> q+
<JonathanNeal> q+
<hdv> jhey: you could do something in your options, an exclusion attribute where you could say just exclude the email from the option etc
<gregwhitworth> ack tantek
<hdv> tantek: either approach sarah_h was recommending is a good path to go down
<hdv> tantek: if we go down the route of cloning DOM, selected value could be a pseudo element that you could just style to show the pieces you want to show
<hdv> tantek: all the use cases mention a subset of the information from the richer display being displayed in the selected value display… it feels like that could all be done with CSS
<hdv> tantek: I appreciate the email example, but there are flags and other things we could do here
<hdv> gregwhitworth: it's a separate thing you can aready do
<hdv> d/aready/already
<hdv> s/aready/already
<gregwhitworth> ack masonf
<hdv> jhey: I thnk the most important thing is the developer experience of if you want your value shown, you don't want every developer having to write the boilerplate to do that, making that convenient would be the end goal here
<tantek> +1 jhey
<hdv> masonf: I just wanted to say… my concenr with making it cloneable… the easy example with flags is one thing, but if 99% of use cases do need JS to handle it because they are more complex, then I would want to avoid making the whole thing more complicated
<hdv> masonf: maybe this is more of a version 2 thing, as we learn how common this use case it
<hdv> s/it/is
<tantek> it sounds like most of these use-cases could be done with CSS, without JS. so I see the opposite, that 99% of the use cases won't need JS.
<gregwhitworth> q+
<sarah_h> +1 to what mason said
<gregwhitworth> ack JonathanNeal
<tantek> q?
<flackr> q+
<hdv> JonathanNeal: I think that this use case and the problems we're trying the solve, and some of the solutions, could be its own thing… 
<hdv> ack greg
<hdv> gregwhitworth: my issue is how to do it in a backwards compatible way
<hdv> gregwhitworth: so like jhey said most people would expect it to be there
<hdv> gregwhitworth: let's say a year from now we see that 60% of the scenarios, or 30 or 40… how can we still change it then?
<hdv> gregwhitworth: that's my concern
<sarah_h> q+
<hdv> masonf: it could be opt in
<hdv> gregwhitworth: ok I'm sold
<gregwhitworth> ack flackr
<tantek> curious what frameworks do for this, or rather, do any frameworks clone the DOM like we're proposing or do they all only provide "innertext"?
<hdv> flackr: I think you covered what I wanted to say, gregwhitworth, how do upgrade in a backwards compat way
<hdv> flackr: I think CSS is a natural way what it is from the option, it seems natural to change the appearance and hiding certain things just with CSS
<gregwhitworth> ack sarah_h
<hdv> sarah_h: this might be a terrible idea… it is common to clone a portion of an option rather than the entire thing… what about an idref association, where you say you selected-value-for and point to an ID that could be a child or self referencing, and then that element is cloned
<tantek> interesting, like a 'value-for' IDREF attribute
<hdv> scotto_: that's kind of what I was hinting at with the template element point
<hdv> gregwhitworth: could still be add on theoretically, like if it is not there we could still use innerText
<flackr> unless the default should be copy the innerHTML in the absence of value-for
<hdv> gregwhitworth: the proposed resolution I was going to put forward is we use it as is… I don't know now, I'm torn
<hdv> gregwhitworth: so let's not resolve on it today
<jhey> Icon fonts do worry me with using the innerText
<JonathanNeal> In that case, what happens to <optgroup>?
<hdv> gregwhitworth: feels like there are now 3 paths forward
<hdv> gregwhitworth: I will formulate the different paths forward
<hdv> gregwhitworth: thanks everyone!
<dandclark> Tricks with imperative slotting seem to have problems when the popup is open, when the option would need to be appear in two places simultaneously.
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been flackr, JonathanNeal, hdv, scottkellum, masonf, scotto_, bkardell_, dandclark, una, chrishtr
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/10/27-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye