1753324 - Override for user-select: none

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)

Description

[Martin Thomson [:mt:]]

https://meet.google.com/ is currently applying user-select: none to body (as -moz-user-select). This makes text selection on that page impossible, even when the Alt key is held down, which is our usual key for disengaging other ways in which sites override content accessibility functions (like the context menu).

user-select: none is useful if applied with care and thought. Here it is being applied too broadly.

I've tested other sides that use user-select: none and found that text marked this way cannot be selected or copied. Can we build an override modifier so that even if sites abuse this power users don't have to resort to opening devtools?

Comment 1

[jscher2000]

CSSWG acknowledges that sites may use this property to frustrate users and suggests they should not do this (tsk tsk):

Note: none is not a copy protection mechanism, and using it as such is ineffective: user agents are allowed to provide ways to bypass it, it will have no effect on legacy user agents that do not support it, and the user can disable it through the user style sheet or equivalent mechanisms on UAs that do anyway. Instead, none is meant to make it easier for the user to select the content they want, by letting the author disable selection on UI elements that are not useful to select. Tools such as CSS validators, linters or in-browser developer tools are encouraged to use heuristics to detect and warn against incorrect or abusive usage that would hamper usability or violate common user expectations.

Authors should be careful about not constraining the user unnecessarily. For example, setting user-select: none on the root element, and relaxing that restriction on a handful of elements the author judges useful to select can be frustrating to users:

• Clicking in empty areas to undo the current selection will no longer be effective
• The author may have overlooked some areas which should be selectable
• Areas may be added later to the page without remembering to make them selectable
• The user may want to select pieces of text other than the main content, for instance to look them up in a dictionary or in some translation tool, or to look for warnings and error messages in a search engine…

Instead, a good practice is for authors is to selectively apply user-select: none to elements which seem likely to be accidentally selected when doing so would interfere with the more likely intended action. Accidentally leaving parts of the page that are unlikely to be interacted with selectable will likely cause much less frustration to users than the opposite.

However, both bad faith use and mistakes happen, and Reader View isn't available on all sites, so in the interest of user productivity, a modifier key or maybe even a preference would be a good idea.

Recent SUMO thread: https://support.mozilla.org/questions/1368642 (copy protection scenario)