[css-ui-4] Make selection change behavior configurable

[saschanaz]

Following #319.

Problem: MSEdge Insider Preview build recently changed its behavior not to change selection when clicking non-selectable area to match the requirement from #319. This breaks my app behavior which targets Windows 10 store platform.

Background: Web pages by default allows user selection for the whole page area, while desktop apps by default blocks it and wants to control selectable area strictly. This means the whole background of page body is unselectable, and it again means unselecting is hard.

Take a look here (Firefox and Edge is preferred, Chrome has slightly different behavior): http://codepen.io/SaschaNaz/pen/wdeqZX

Imagine users selected their texts to copy and paste, and then wants to unselect. Previously with MSEdge the user can just click anywhere on the page, but now the user has to think carefully to unselect without opening a popup. (The only way on MSEdge is to right-click anywhere)

Since unselecting got hard, I suggest a way to allow previous Chromium behavior, where unselection happened when clicking non-selectable area.

[frivoal]

In typical native apps, clicking on UI areas does not deselect any previously selected text. I don't quite see why we need a different behavior here.

Why apply user-select:none to areas that have nothing selectable anyway, especially if you're still hoping that a user interacting with that area would affect the selection?

Wouldn't your problem be solved if you applied user-select:none less aggressively, and let the whole content area be selectable (instead of just the text parts in the content area), keeping user-select:none for tool-bars and other UI centric components?

Besides making deselecting easier, this would have additional benefits. In the example you sent, if an image fails to load and the alt text is shown instead, it would not be selectable. What is to be gained by preventing users from selecting that?

[saschanaz]

In typical native apps, clicking on UI areas does not deselect any previously selected text.

I would say "it depends". For example, imagine if you use Facebook app and you somehow want to copy someone's post. The current Facebook app allows user to cleanly select text only inside the post, without copying any UI components. Deselecting works by clicking outside of the post.

The original discussion was about editor apps and I agree the new behavior is helpful there, but not for all type of apps.

Why apply user-select:none to areas that have nothing selectable anyway, especially if you're still hoping that a user interacting with that area would affect the selection?

This is to prevent copying unwanted texts. You probably don't want to copy nickname, timestamp, like count, etc.

In the example you sent, if an image fails to load and the alt text is shown instead, it would not be selectable.

Specifically I mentioned Twitter there, you will not expect any images fail to load on Twitter and instead show alternative text.

[frivoal]

To me, the behavior you're describing seem achievable by setting user-select: none just on the bits of UI that you don't want selected, leaving the empty areas at the initial value, instead of setting user-select: none on the root of the page, and setting it back to auto on whilte-listed bits of content.

With the current behavior, we can get both cases to work, while if we switched to user-select: none being able to cancel the current selection, there would be no way to make parts of the page unable to affect the selection.

[FremyCompany]

Allowing selection to start in "empty spaces" on the root of the page mean you cannot prevent selection to span across multiple -ms-user-select:element elements. That is usually not a behavior apps want to allow. I still have mixed feelings on this one, I think. Test case

[FremyCompany]

My point is that the advice given when you want app-like selection has always been to set none as the default and override as needed with element for your controls, so that your selection always start inside a contained selection wrapper.

[css-meeting-bot]

The CSS Working Group just discussed Make selection change behavior configurable, and agreed to the following resolutions:

• RESOLVED: option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern

The full IRC log of that discussion

<dael> Topic: Make selection change behavior configurable
<Florian> Github: https://github.com//issues/1317
<dael> github topic: https://github.com//issues/1317
<dael> Florian: User-select: none makes it impossible to select things. But also if something is selected somewhere else in the doc and you click in a user-select: none area the spec says this should not effect existing selection
<dael> Florian: I believe we picked this because in native UI there are often places that are inert. However, someone has said they sometimes want the other way around where if you click in a user-select: none area it should unselect
<dael> Florian: Example for that I think was a FB page with posts. Post content is selectable, but if you click in the empty areas, like the margin around the post, people expect that to undo the selection
<dael> Florian: My original reaction was then don't use user-select:none However people that do app-like things do user-select:none on the root and make some small area selectable.
<dael> Florian: Maybe they shouldn't be doing that, but maybe there is a need. We should either flip the behavior or create the ability to do the two behaviors. What do people think?
<dael> fantasai: I don't think flipping makes sense. It seems there are two behaviors wanted here.
<dael> Florian: I think I agree flipping wouldn't be good. I'm less sure if we want 2 values or we recommend people don't do user-select:none on the root and instead selectively apply it.
<dael> Rossen_: Have we circled back witht he editing group and asked if they have any best practices for such scenarios?
<dael> Florian: We have not but could
<dael> Rossen_: I think they have reviewed these kinds of patterns. I don't think we should re-invent the wheel here. If they have a reocmmendation we should match.
<dael> Florian: I think it's fair to ask. I'm not sure we'llg et an answer as the editing TF is focused on content:editable that isn't primarily about selection. This is also used in non-editing places.
<dael> Rossen_: I don't disagree, but since editing is their charter I would expect most people would be expert in editing behaviors and use cases so they may have a recommendation. If they don't we're at square one.
<dael> Florian: Even if they do, this isn't about just editing so we may not want to jsut take it. We need to think about non-editing use cases. That's the majority of the use cases. This is about making tool bars and labels non-selectable so when people select somehting to copy/paste they don't get UI as well
<dael> Florian: It does interact with editing, but it's not limited to that
<dael> Rossen_: What are the options on the table?
<dael> Florian: 1) no change 2) change from current and make it so clicking in unser-selection:none undoes current section 2) have two values, one for each behavior.
<dael> Florian: Together with option 1 it comes with add a note about setting user-select:none on the root having undesireable behavior
<dael> Rossen_: What do people think? Can we live with #1?
<dael> bdc: From a designer perspective I feel this is a very minor issue I've never seen before. I feel we have everything in place to leave as-is. I would personally gow ith option 1
<dael> Rossen_: Thanks.
<dael> Rossen_: Other opinions or should we reasove?
<dael> Rossen_: Objections to option 1: no change and add a non-normative note explaining adding this on the root isn't a great pattern
<dael> RESOLVED: option 1: no change and add perhaps a non-normative note explaining adding this on the root isn't a great pattern