html icon indicating copy to clipboard operation
html copied to clipboard

Published 20 hours ago • verified publisher icon whatwg

Should <button> have `user-select: none;` by default?

Open karlcow opened this issue 2 years ago • 5 comments

Opening because there are different behaviors across WebKit, Blink and Gecko.

Selectable in WebKit and Blink, but not in Gecko

data:text/html,Foo <button>Bar</button> Baz

Not selectable in WebKit, Blink and Gecko.

data:text/html,Foo <input type="button" value="Bar"> Baz
  • https://bugs.webkit.org/show_bug.cgi?id=244448
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1356522
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1763744

karlcow avatar Aug 29 '22 05:08 karlcow

If we're OK with the inconsistency between the two elements, then the simplest proposal here is to just make button selectable and input not-selectable, and then only the { Gecko, button } case has to change.

I don't think consistency here is especially important, but maybe someone feels differently. So far the evidence seems to be that a single web developer noticed the inconsistency and filed bugs on both Blink and WebKit.

domenic avatar Aug 29 '22 06:08 domenic

The Blink/WebKit behavior isn't a matter of "just" making the button selectable. To put that behavior in the spec, the spec would need to explain what Blink and WebKit do to make mouse events on the button press the button instead of starting a selection.

OTOH, the Gecko approach of consistency between input and button makes sense. The page referred to in in the Gecko bug report via https://github.com/webcompat/web-bugs/issues/102132 doesn't show a legitimate use case: The page is self-inconsistent and I can't infer why it is using the button element the way it uses it.

hsivonen avatar Sep 13 '22 08:09 hsivonen

The page is self-inconsistent and I can't infer why it is using the button element the way it uses it.

Agreed. This is the webdev side, why did they choose a button instead of a link in this UI. https://a11y-101.com/design/button-vs-link https://uxmovement.com/buttons/when-to-use-a-button-or-link/ https://css-tricks.com/buttons-vs-links/ Parts of an old debate. We will not solve it here.

On the user side, on the other hand, with this specific case, the selection of the content is useful. One of the questions is more why the text should not be selectable, when ones want to extract the content of the page. fwiw, "save as text" from Firefox gives the text in the button.

*Release Year* 	
April 7, 2022
*Genre* 	
Adventure <https://nsw2u.in/tag/Adventure>
Puzzle <https://nsw2u.in/tag/Puzzle>
Action <https://nsw2u.in/tag/Action>
Lifestyle <https://nsw2u.in/tag/Lifestyle>
*Publisher & Developer* 	
Frogwares <https://nsw2u.in/tag/Frogwares>

And the good question from @hsivonen

To put that behavior in the spec, the spec would need to explain what Blink and WebKit do to make mouse events on the button press the button instead of starting a selection.

Currently on Safari, I didn't find any key combination which is working when the cursor is above the button for selecting the text. The selection is working only if the selection starts outside of the button.

karlcow avatar Sep 13 '22 18:09 karlcow

The selection is working only if the selection starts outside of the button.

And I think that is rather weird behavior. One may select the text, but clearing the selection doesn't work the normal way by just clicking the selection. One has to click outside the button. That is at least the behavior in Chrome.

smaug---- avatar Sep 13 '22 18:09 smaug----

Let's take another example. Maybe more obvious. Let's say we have a form, and you have selected all the options. You might want to select everything and paste to keep memories of the choices.

  1. Enter
data:text/html,<!doctype%20html><html>foo%20<select><option%20value="vege">Vegetarian</option><option%20value="omni">Omnivore</option><option%20value="fish">Fish%20only</option></select>
  1. Choose Vegetarian from the options list
  2. Select All
  3. Copy
  4. Paste

Results:

  • Gecko:
    • select not selectable,
    • copy/paste gives "foo "
  • WebKit:
    • select selectable,
    • copy/paste gives "foo "
  • Blink:
    • select selectable
    • copy/paste gives "foo \nVegetarian"

not very consistent.

karlcow avatar Sep 13 '22 19:09 karlcow

Note the css-ui spec includes (just before the inline issue) the following:

The following additions are made to the UA stylesheet for HTML:

button, meter, progress, select { user-select: none; }

valtlai avatar Sep 24 '22 12:09 valtlai

I am new to the open-source can you assign this to me?

YASHWANTHKESAGONI avatar Jan 22 '23 19:01 YASHWANTHKESAGONI

Any update on this issue? As comment pointed out above, this is already specced in css-ui. It would be great to have interoperability across browsers. I am happy to help implement this in Blink.

dizhang168 avatar Nov 30 '23 21:11 dizhang168

I forget exactly everything that was discussed at WHATNOT, but there would be risk of breakage if chrome puts user-select:none on buttons. There could be use cases where users expect to be able to select text on buttons either by clicking from outside and dragging over the button or by selecting all by pressing ctrl+a. Websites can probably see it too by executing editing commands.

If we did the work to change to user-select:none, we would probably just find evidence of people wanting user-select:auto in regression bugs. If that is motivating to implement user-select:auto in firefox, then we could give it a try.

I agree that the behavior in chrome and webkit is kind of magic in the way that it doesn't allow selections that start when the user clicks inside the button, but I don't think that is a great justification for changing chrome to user-select:none. If diving into the code to explain how this works would also help motivate firefox to implement user-select:auto on buttons, then we can help with that too.

josepharhar avatar Dec 19 '23 20:12 josepharhar

Additional comment on https://github.com/WebKit/WebKit/pull/10017#issuecomment-1911294222 for the WebKit project

This change will have an impact in accessibility support of these elements. So we will need to find an alternative for accessibility before going ahead with this change. To determine the text under an element, accessibility relies in the same machinery as editing, namely TextIterators. So if the text under a cannot be extracted, say to copy to the clipboard, accessibility will not be able to retrieve the textual label either, thus making the button label-less for an accessibility client. Further investigation and possible implementation changes would be required to ensure accessibility can retrieve the text under an element with user-select: none.

karlcow avatar Jan 26 '24 02:01 karlcow

Just a drive by comment to say that imo <input type="button|reset|submit"> behaviour* should at least internally within any single browser engine be consistent with button (and file selector button).

  • I say behaviour not styles because it seems WebKit has styles that suggest input buttons should be selectable but they're not actually.

I left a comment on the CSS issue for this with what I found across browser styles relative to the CSS-UI spec https://github.com/w3c/csswg-drafts/issues/9709#issuecomment-2041439088

I do think we should strive for interopability (and consistency) here.

lukewarlow avatar Apr 07 '24 11:04 lukewarlow

The way I would expect this to be sliced:

  • We don't have user-select:none by default and note that user-select is not a property that is honored for appearance:auto widgets. (This might need some specification effort.)
  • Implementation can decide whether they want their appearance:auto widgets to be selectable or not. It should generally be up to them how appearance:auto widgets behave after all.
  • Ideally they make those choices consistently across similar widgets.

annevk avatar Apr 08 '24 07:04 annevk