[css-ui-4] let user-select:contain prohibit selection from outside

[yoichio]

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

user-select:contain stops selection leaking from inside to outside, but often
we want to prohibit selection from outside.
For position: absolute, we want selection on normal layout elements to skip over the abs elements but
also want user to be enable to select the element.
For form/editable element, it is also strange that selection from outside can go into the form.

How about make user-select:contain more strict that prohibits selection transit?

[frivoal]

So in essence, you would like a change from this sentence

The UA must allow selections to extend across this element, and such selections must include the content of the element.

to

The UA must allow selections to extend across this element, and such selections must not include the content of the element.

Maybe this is a good idea instead of the current behavior, or maybe this is a good idea of an additional value with a different behavior.

However, we have a problem: For this to work, we would need selections that can contain multiple DOM ranges. Currently, only firefox supports this, and as far as I know, no other browser plans to implement that behavior.

If it would be acceptable to have the behavior you ask in browsers like firefox (and probably only firefox), and to keep the current behavior everywhere else (similarly to how user-select:none skips the content in Firefox only), then we can do this. Not saying everyone will agree, but at least it is arguable possible. Otherwise, I don't think we have a realistic path forward.

[frivoal]

I don't mind specifyng this (probably as an user-select: auto | text | all | [ [ none | contain ] skip?]) if there is interest from browsers, but otherwise it is not a useful exercise. Adding it to the Agenda to see if this is worth considering or not from that point of view.

[astearns]

@frivoal should this go on the weekly agenda, since we didn't get to it at the F@F meeting?

[css-meeting-bot]

The CSS Working Group just discussed let user-select:contain prohibit selection from outside , and agreed to the following:

• RESOLVED: don't fix and explain why in the issue

The full IRC log of that discussion

<dael> Topic:let user-select:contain prohibit selection from outside
<dael> github: https://github.com//issues/1815
<dael> florian: There is a value that corrisponds to the behavior everyone has. We say if you start selection before element and end after then selection must include the element in the middle. Someone suggested we should exclude it. So content before and after, but not contained element.
<dael> florian: afaict this is not what people impl. Only FF supports multi-part selections. However the none value is a middle ground. Browsers that support multi-part must have 2 part selection and others must make one big selection. but they can exclude the middle part.
<dael> florian: That's for none and corrisponds to what people impl. Doesn't corrispond for contain, but we could do it.
<dael> fantasai: What's most reasonable for use case?
<dael> florian: no use case mentioned. We are mostly interop
<dael> myles: No use case plus interop seems clear
<dael> florian: This is from google. Anyone know why?
<dael> fantasai: You can say we're leaning to not because interop and we have no use cases. If they come back with use cases we can reconsider
<dael> Rossen_: Proposal: resolve no fix and expalin why in the issue
<dael> RESOLVED: don't fix and explain why in the issue

[frivoal]

@yoichio

The existing behavior, which is not to skip over such elements, is interoperable. Even when the value is not explicitly supported, the behavior is the one you get on (for example) a textarea.

If you have strong use cases that justify changing from what people currently do, we can reopen, but otherwise, the WG has decided to close as wontfix and to keep the specification (and implementations) unchanged.

We'd appreciate if you could let us know whether that's acceptable to you (and if not, why not).

[yoichio]

Thanks for discussing about this.
O.K. Since we don't have any strong request from user, let it be wontfix.