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

karlcow · 2022-08-29T05:45:04Z

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

The text was updated successfully, but these errors were encountered:

domenic · 2022-08-29T06:05:30Z

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.

hsivonen · 2022-09-13T08:30:10Z

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 webcompat/web-bugs#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.

karlcow · 2022-09-13T18:54:47Z

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.

smaug---- · 2022-09-13T18:59:20Z

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.

karlcow · 2022-09-13T19:11:36Z

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.

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>

Choose Vegetarian from the options list
Select All
Copy
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.

valtlai · 2022-09-24T12:07:48Z

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; }

https://bugs.webkit.org/show_bug.cgi?id=244448 rdar://99262559 Reviewed by NOBODY (OOPS!). In the section 6.1. Controlling content selection had this recommendation for the UA stylesheet for HTML. button, meter, progress, select { user-select: none; } https://drafts.csswg.org/css-ui/#content-selection seeAlso whatwg/html#8228 This will need to be unprefixed once Bug 208677 is fixed https://bugs.webkit.org/show_bug.cgi?id=208677 * LayoutTests/accessibility/mac/search-predicate-from-ignored-element-expected.txt: * LayoutTests/accessibility/mac/search-predicate-from-ignored-element.html: * LayoutTests/accessibility/mac/textmarker-range-for-range-expected.txt: * LayoutTests/editing/pasteboard/paste-noscript-expected.txt: * LayoutTests/editing/pasteboard/paste-noscript-xhtml-expected.txt: * Source/WebCore/css/html.css: (button, meter, progress, select):

dizhang168 · 2023-11-30T21:36:15Z

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.

josepharhar · 2023-12-19T20:31:25Z

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.

karlcow · 2024-01-26T02:24:19Z

Additional comment on WebKit/WebKit#10017 (comment) 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.

lukewarlow · 2024-04-07T11:57:19Z

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 w3c/csswg-drafts#9709 (comment)

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

annevk · 2024-04-08T07:32:43Z

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.

domenic added topic: forms interop Implementations are not interoperable with each other topic: style labels Aug 29, 2022

This comment was marked as spam.

Sign in to view

karlcow mentioned this issue Feb 13, 2023

Should <button> have user-select: none; by default? WebKit/WebKit#10017

Open

oliviertassinari mentioned this issue Jul 20, 2023

[website] Add Base UI marketing page mui/material-ui#36622

Merged

13 tasks

josepharhar added the agenda+ To be discussed at a triage meeting label Nov 30, 2023

dizhang168 mentioned this issue Dec 14, 2023

[css-ui] Clarify why user-select: none should be the default for button, meter, progress, select w3c/csswg-drafts#9709

Open

past mentioned this issue Dec 15, 2023

Upcoming WHATNOT meeting on 12/14/2023 #9966

Closed

past removed the agenda+ To be discussed at a triage meeting label Dec 15, 2023

past mentioned this issue Jan 11, 2024

Upcoming WHATNOT meeting on 1/11/2024 #9993

Closed

past mentioned this issue Jan 26, 2024

Upcoming WHATNOT meeting on 1/25/2024 #10052

Closed

past mentioned this issue Feb 8, 2024

Upcoming WHATNOT meeting on 2/8/2024 #10094

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

karlcow commented Aug 29, 2022

domenic commented Aug 29, 2022

hsivonen commented Sep 13, 2022

karlcow commented Sep 13, 2022

smaug---- commented Sep 13, 2022

karlcow commented Sep 13, 2022 •

edited

Loading

valtlai commented Sep 24, 2022

This comment was marked as spam.

dizhang168 commented Nov 30, 2023

josepharhar commented Dec 19, 2023

karlcow commented Jan 26, 2024

lukewarlow commented Apr 7, 2024 •

edited

Loading

annevk commented Apr 8, 2024

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

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

Comments

karlcow commented Aug 29, 2022

domenic commented Aug 29, 2022

hsivonen commented Sep 13, 2022

karlcow commented Sep 13, 2022

smaug---- commented Sep 13, 2022

karlcow commented Sep 13, 2022 • edited Loading

valtlai commented Sep 24, 2022

This comment was marked as spam.

dizhang168 commented Nov 30, 2023

josepharhar commented Dec 19, 2023

karlcow commented Jan 26, 2024

lukewarlow commented Apr 7, 2024 • edited Loading

annevk commented Apr 8, 2024

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

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

karlcow commented Sep 13, 2022 •

edited

Loading

lukewarlow commented Apr 7, 2024 •

edited

Loading