[selectmenu] Should the text inside <option>s be selectable?

[mfreed7]

It feels like option text (within the popped-up listbox) should be user-selectable, so they can copy it to the clipboard. But perhaps there's an a11y or other reason not to allow that. I just wanted to ask the question explicitly.

[scottaohara]

hmm. good question. not something presently possible with select element options, and not the most straight forward to do with other interactives, like buttons (i can mouse down outside of a button and then select the text by mouse moving/keyboard moving the text caret that way. but directly mouse down / dragging on a button other interactive controls that listen for a mouse up/down click event would have conflicts? maybe a larger issue than a11y

[mfreed7]

Thanks - very good points. And thanks for pointing out that you can't currently do this on <select>, or at least in any way that I know of. I hadn't noticed that.

Perhaps the best would be a non-!important UA rule that says option {user-select:none}? Then if there's actually a use case, developers could override that, but in most cases, text isn't selectable?

[scottaohara]

i think that makes sense. the returned value for the selectmenu in the triggering element should behave similarly to button, in that someone could click/drag or keyboard shift key press and left or right arrow key to include the visible text of that trigger. that'd be one way someone could copy the currently chosen option at least.

i dunno. it's a feature that i could see people wanting when they want it. but otherwise, not really caring too much about since it's not a common thing that can be done (easily)?

[brechtDR]

Couldn't this actually be beneficial for A11Y in some manner? Being able to copy your options for when you're having a messaging chat with a person and you want to ask which option to take. If it's not harmful in any way for A11Y, I think it could be a nice-to-have for some people.
I'm thinking about this case from a personal perspective, helping a less tech-savy elderly person out with a form submission via chat.

[josepharhar]

I don't have a strong opinion, but I think that we should leave it selectable because other clickable/selectable elements like <button> are user-select:auto. However, I can't seem to actually select the text in the <button>s with a mouse.
It also looks like the selectmenu implementation in chromium behaves the same way: There is no user-select:none rule, but you can't select the text with a mouse.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] Should the text inside <option>s be selectable?, and agreed to the following:

• RESOLVED: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] Should the text inside <option>s be selectable?
<gregwhitworth> *wave*
<dbaron> ScribeNick: jarhar
<gregwhitworth> github: https://github.com//issues/687
<jarhar> masonf: this ones pretty straightforward in terms of description, should the text be selectable when the listbox pops up should you be able to select these things
<gregwhitworth> q+
<dandclark> q+
<jarhar> masonf: its not specced like this, but its hard to select some things and in select you cant select any of the text
<jarhar> masonf: im ok with anything just want to do the right thing for the user
<jarhar> gregwhitworth: there is no looking at the different web properties any consistency i can find in terms of comboboxes and select
<jarhar> gregwhitworth: lets just pick a default that makes sense, i literally dont care
<JakeA> q+
<gregwhitworth> ack gregwhitworth
<jarhar> gregwhitworth: we should probably use something that can be overridden by the css property, people should be able to make their stuff selectable or not selectable
<gregwhitworth> ack dandclark
<jarhar> dandclark: lacking a strong reason to go one way or the other, lets go with whats in the existing implementations
<jarhar> dandclark: native select and other datetime control popups the text is not selectable
<jarhar> dandclark: i was seeing the text not being selectable in bootstrap etc
<Brecht_DR> q+
<scotto> q+
<jarhar> dandclark: i do get a carrot when hovering over things in listbox which seems weird, preference to make it not selectable
<jarhar> dandclark: authors should still be able to override
<JakeA> _speaking_
<gregwhitworth> ack JakeA
<dbaron> s/still be able to override/still be able to override (not a !important rule)/
<dbaron> s/carrot/caret/
<jarhar> jakea: so you want to be able to put richer content in selectmenu, so it might be worth thinking about whether links should be clickable
<jarhar> jakea: you could imagine a select and one of the items has a trash can to delete items or add items
<jhey> q+
<jarhar> jakea: if use no user-select, does that impact that as well?
<jarhar> masonf: its a button though, you could still click it you just cant highlight the text
<jarhar> jakea: that clarifies it, i didnt know if this was just about select
<gregwhitworth> q+
<jarhar> jakea: if we are going with consistency with select, theres a difference there. select just has one thing per option
<jarhar> jakea: if we are adding richer content, then maybe consistency with select is not the goal
<jarhar> masonf: a selectmenu is primarily still just for picking options
<jarhar> masonf: if there is something else to do with options that is an accessibility gray area
<gregwhitworth> ack Brecht_DR
<jarhar> brecht: agree that defaults with select
<jarhar> brecht: if it doesnt have any accessibility issues to make it selectable then i dont see any reason we shouldnt be able to override it with css
<jarhar> brecht: could add value to this new ui
<gregwhitworth> ack scotto
<jarhar> scotto: i agree with not making the options inherently selectable
<gregwhitworth> ack gregwhitworth
<jarhar> scotto: the rich content throws a wrench into this
<jarhar> scotto: the only thing that comes to mind for an accessibility thing is more for if they have a motor disability where they are trying to select an option but one could accidentally click and drag and select a piece of the text, how is that supposed to behave
<jarhar> scotto: how do we know if someone is trying to select an option or they have a tremor and now theyve selected the text
<jarhar> scotto: does that mean they need to click again
<jarhar> scotto: buttons dont behave this way for similar reasons
<jarhar> scotto: if its overridable thats probably enough but it shouldnt be the default
<dandclark> That's a great point
<gregwhitworth> ack jhey
<jarhar> jhey: mason hit what i was going to say
<jarhar> jhey: if you want to add buttons to things youd probably just create another control. a button that just anchors a popover to it
<jarhar> gregwhitworth: jake the scenario you brought up has been brought up before, like a composited control
<masonf> Proposed resolution: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
<dandclark> +1
<masonf> RESOLVED: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
<jarhar> gregwhitworth: what this means is that authors can override user-select:none

[josepharhar]

I'm not sure if this needs any text in the explainer, but it will at least be in the user agent stylesheet and I'm adding an implementation with WPTs here: https://chromium-review.googlesource.com/c/chromium/src/+/4370763