Disallow selecting the text of buttons

[delvh]

Currently, it is possible to select the text of buttons.
I don't see a reason why, though. A button should (by default) not allow selecting its text.

This PR changes this by adding a new style class that disallows text selection.
In the future, if you want to make something unselectable, simply give it the style class unselectable.
If you want every element of another CSS selector to be unselectable, simply use &:extend(.unselectable); inside the selector body.

Originated in #19007 but is thematically irrelevant.

This could even be backported as it is a non-breaking change that enhances UX.

[silverwind]

Why not just

button {
  user-select: none;
}

Reasons:

1. Keep it simple. If something is not a <button>, it will have a11y problems and should be changed to such.
2. Vendor prefixes are not needed, all browsers we support do support the unprefixed variant since many years now.

[silverwind]

user-select: none; will be more readable to someone unitiated to Less. Vendor prefixes are not needed.

[delvh]

CanIUse gives me only 75% unprefixed.
prefixed, this goes up to 94%.
(https://caniuse.com/?search=user-select)
This would mean that it would not work correctly for one out of 4 people.
I think that's a bit too much.

Also, there are a lot more pseudo buttons than you think there are.
According to my quick search (ag 'class=".*button.*"' | grep -v '<button' | wc -l ), there are 335 of those... Have fun fixing all of them.

[silverwind]

Right, Safari still needs -webkit-, so that must be kept, sorry I missed it on MDN.

[silverwind]

there are 327 of those

Maybe compromise on button, .button 😉

[delvh]

Yeah, I can definitely throw out the unneeded prefix rules for -khtml, -ms and -moz.

That presents me with a problem: There might be a lot more components that might want not to be selectable.
So, which of the following options would you recommend?

• Remove the style class completely, adding its rules to each needing selector (pretty messy to write or maintain)
• Extend selectors that should not be selectable with the style class (as it is now - easy* to write and easy* to maintain)
• Remove the &:extend(.unselectable) and instead add the style class to every component that qualifies for it (messy to write but easy to maintain)
• Did I forgot something?

My personal choice is the current approach because this syntax is not too obscure, and if I'm writing less and see a syntax I don't understand, I can easily google it. To give you an example:

will be more readable to someone unitiated to Less

That was my first time writing (not CSS compliant) less, I simply googled whether I can extend a styleclass in less and used the first StackOverflow result. So, it should be possible to understand even for newbies.
Also, extending has the benefit that users can directly see which attributes will apply without having to skim through the entire web_src/less directory for potentially counter-productive rules, i.e. because of deeply nested rules as it is currently.

[wxiaoguang]

Generally L-G-T-M. I prefer to keep only user-select and -webkit-user-select. Other prefixes are so rare .....

[delvh]

@silverwind, I would like still an answer to the question above.

[wxiaoguang]

No more comment, will get this PR merged.