[css-ui] user-select: none and selectionchange event

[caub]

https://drafts.csswg.org/css-ui-4/#propdef-user-select

Follow up from https://bugs.chromium.org/p/chromium/issues/detail?id=621543, it's a behavior at the limit between CSS and JS. Firefox doesn't fire selectionchange events and doesn't change the text selection when clicking in an element with a user-select: none parent. Chromium and Edge don't respect that

[frivoal]

Hi. I feel like I missing a bit of context, so I am not sure I fully follow what you're asking, but if I get it right, you think:

• if something is already selected, clicking in a user-select:none element should not change that selection
• consequently, no js event relating to the selection being changed should be fired, since it isn't being changed.

For the first item, I think this is reasonable, but I am not sure it should be mandated: if UAs want to do something else (e.g. trying to select a user-select:none element cancels the current selection), maybe that's ok. Then again, as far as I can tell, all browsers keep the selection as it is, so maybe we can indeed specify the status quo. Maybe we could add something like this to the spec:

If some part of the document is selected, and the user attempts to start a new selection in an element where user-select is none, the existing selection must not be discarded or changed.

On the other hand, regardless of whether we include the requirement above or not, if the selection is indeed not changed, I agree no event should be fired. But that's out of scope for this spec: this event is not defined in css-ui-4, but in the selection API spec. The current definition there seem to say what you'd want, but if you want clarifications to it, I suggest filing an issue there.

[frivoal]

Agenda+:
Do we want to include either of the following sentences (or something close) in the defintion of user-select: none, or do we want to leave it up to UAs?

If some part of the document is selected, and the user attempts to start a new selection in an element where user-select is none, the existing selection must not be discarded or changed.

or

If some part of the document is selected, and the user attempts to start a new selection in an element where user-select is none, the existing selection must be discarded.

Chrome and Firefox do the first one, but and Edge Safari do the second one. Do we want to align behavior one way or the other, or are we comfortable with leaving this up to the UA?

[caub]

I think it's Firefox only that does the first one (and in my opinion the right behaviour)

Chrome 54.0.2816.0 dev-m (64-bit) / win10: http://i.imgur.com/KfMaBGa.gif

[frivoal]

You're right. Chrome's behavior is somewhere in between: if you have a selection, and simply click in a user-select:none element, the selection is not changed, but if you start dragging, it is. I believe this behavior is likely to change when https://bugs.chromium.org/p/chromium/issues/detail?id=481985 is fixed, but how it will change is uncertain.

[astearns]

We need some input from the editing task force on this.

[frivoal]

Just for the record, Safari is doing the same as Chrome: nothing if you just click, unselect if you drag.

[fredck]

I would definitely expect to have no selection related behavior when clicking such element. Neither the current selection changes nor the selectionchange event is fired. Click events are expected ofc.

It's also reasonable to assume that only the selection can be dragged. Therefore, if clicking an element doesn't move the selection to it, dragging should have no effect on the current selection. If such dragging instead crosses the element boundaries and moves over selectable text, then it is acceptable that the selection changes, performing the usual dragging operation to select such text.

[johanneswilm]

I agree with @fredck. One thing that this could be used for is the UI toolbar of a text editing app. Setting user-select: none; could prevent the user from accidentally selecting part of the text in the toolbar menu, thereby losing the current caret position within the text that is being edited. For that use case, click events would be useful.

[gked]

Agreeing with Firefox's behavior. Will fix this in Edge: https://msedgeportal.trafficmanager.net/en-us/microsoft-edge/platform/issues/8888287/

[frivoal]

Since both Edge and Chrome intend to match Firefox, and with feedback from multiple people involved in js-based editors (CKEditor's fredck, Johannes and caub) going in the same direction, we have a strong candidate for resolving this:

Attempting to start a selection in an element where 'user-select' is ''none'', such as by clicking in it or starting a drag in it, must not cause a pre-existing selection to become unselected or to be affected in any way.