1036853 - Implement user-select: contain, which should contain the selection range

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

STR:

1. Open test case
2. Start selecting the numbers "12345678"
3a. Without releasing the mouse button, swipe up and attempt to select the name above, or,
3b. Release the mouse button and Ctrl+A

Expected:

1. Selection range should stop at the number element

Actual:

1. Select the whole page


Note: I am not sure if this is a dup of bug 739396.

Background: This is the use case for FxOS applications I can think of that is most useful.

Comment 1

[Mats Palmgren (inactive)]

http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select
element
  "One element at a time may be selected"

My understanding is that it's meant for lists, menus and such.
A "selection gesture" in such an element would select exactly one
child element (<option> etc) and the <option>s / items would have
user-select:all to get a traditional menu-like behavior.
I think the 'elements' value was intended for <select multiple>,
i.e. the same as 'element' but allowing more than one child to be
selected.

That's my understanding of the spec intent anyway, I may be wrong.

From your description it seems you want a behavior that's more
like 'user-select: constrain-to-element', that doesn't imply any
granularity.  I agree it would be useful - it describes selection
starting inside a <textarea> / @contenteditable for example.

It seems like IE10 implemented 'element' like that:
https://ie.microsoft.com/TestDrive/HTML5/msUserSelect/Default.html

The selection in lists implies "constrain-to-element" anyway so
perhaps it's not a bad re-interpretation.  As far as I know,
no UA ever implemented the original meaning of 'element(s)'.

I think we should get the opinion of CSS spec folks first though,
before we implement any new behavior.

Comment 2

[StevenLee[:slee]]

Peter is the taking this issue now.

Comment 3

[howie [:howie]]

Hi David, we would like to have your professional opinions here to get things moving, do you mind to comment on Comment 1 ? Thank you :)

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Mats Palmgren (on vacation) from comment #1)
> http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select
> element
>   "One element at a time may be selected"
> 
> My understanding is that it's meant for lists, menus and such.
> A "selection gesture" in such an element would select exactly one
> child element (<option> etc) and the <option>s / items would have
> user-select:all to get a traditional menu-like behavior.
> I think the 'elements' value was intended for <select multiple>,
> i.e. the same as 'element' but allowing more than one child to be
> selected.
> 
> That's my understanding of the spec intent anyway, I may be wrong.

I'd never considered before that that might have been what it was meant for.  However, even if that's the case, I think it's a bad idea to use the same property to control text selection and the concept of selected items in form controls.  I think -moz-user-select should be about text selection, and should not have anything to do with form controls.

That said, given that understanding, I don't understand what the value of 'element' and 'elements' are, except perhaps that specifying 'elements' on a parent is like specifying 'all' on all of its element children and 'none' on all of its text children.  But I really can't think of a use case for this.

I think it's worth remembering that this property was early in its development stage, and hadn't yet been thought through clearly, so it's worth designing something that makes sense and leads to convergence with other implementations rather than overinterpreting the spec.

> From your description it seems you want a behavior that's more
> like 'user-select: constrain-to-element', that doesn't imply any
> granularity.  I agree it would be useful - it describes selection
> starting inside a <textarea> / @contenteditable for example.
> 
> It seems like IE10 implemented 'element' like that:
> https://ie.microsoft.com/TestDrive/HTML5/msUserSelect/Default.html
> 
> The selection in lists implies "constrain-to-element" anyway so
> perhaps it's not a bad re-interpretation.  As far as I know,
> no UA ever implemented the original meaning of 'element(s)'.
> 
> I think we should get the opinion of CSS spec folks first though,
> before we implement any new behavior.

I don't think it's particularly clear what the intended behavior is.

It doesn't particularly seem to me that the spec wants the implementation that Tim describes in comment 0.  But if that's what IE does with it, it might be reasonable to do.  However, if we do that, it should be documented clearly on MDN.



However, I think it's worth understanding what values other UAs implement and what they do with those values before adding to the set of values that we support.  (For example, we shouldn't add a value called '-moz-none' because our 'none' is buggy and doesn't match other UAs or make sense.)

We should also probably remove support for parsing of values that we don't support.  The code that was written to parse the 'element' and 'elements' values was written before we properly enforced the idea that we wouldn't add support for parsing values that we don't support.  This means that various tests of frame->StyleUIReset()->mUserSelect against the various NS_STYLE_USER_SELECT_* values, written on the assumption that we don't "support" 'element' and 'elements' and perhaps other values, lead to silly behavior for those values.  (We have similar problems for the other -moz-user-* properties.)  There are, of course, compatibility risks with such a change since Web content might be depending on our broken behavior.  But, basically, our implementations of these properties are a complete mess, and for at least some of them, nobody really understands what they're intended to do.  (I think -moz-user-select in particular might be slightly better understood, perhaps by bz or Ehsan.)

I think it's a substantive work item to figure out what the right thing to do here is, and I don't know the answer off the top of my head.  Figuring it out requires describing what behavior the values we implement have, describing how values that other browsers implement behave, and figuring out if there's a path forward that leads to the behavior of the values both converging between implementations and being useful for Web developers.

Comment 5

[Florian Rivoal]

Whatever the original meaning in that old spec was, it is now specified with the IE semantics: http://dev.w3.org/csswg/css-ui-4/#content-selection

Comment 6

[silverwind]

user-select: contain in the current draft is meant to replace the ie-only user-select: element. I has been proposed for Chromium.

https://www.chromestatus.com/feature/5730263904550912

Comment 7

[Sean Voisen (:svoisen)]

Updating this bug summary since we're in the process of unprefixing user-select in bug 1492739, and element is now "contain" in the spec: https://drafts.csswg.org/css-ui-4/#propdef-user-select

Comment 8

[Florens Verschelde :fvsch]

Attachment: devtools-network-user-select-contain.png

We have a use case in devtools, especially in the Netmonitor, where we would like to restrict the scope of "Select All" (Ctrl/Cmd+A) to the blue area where the selection was initiated. The red areas would have user-select: none.

user-select: contain looks like it would be a good fit.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

To be clear this is a feature, right? We don't implement the value right now.

This should be somewhat similar to what nsIContent::HasIndependentSelection does now, I guess, though there are a few callers that seem to make assumptions about what nodes can have that bit set...

Comment 10

[Florens Verschelde :fvsch]

Yep, definitely a feature request.

Another use case I can think of is code editors and rich text editors (not using textarea) embedded in an HTML page. Though we don't need user-select: contain for that in DevTools since CodeMirror intercepts and handles all text selection anyway.