Re: [css-ui-4] user-select

On Thu, Apr 2, 2015 at 10:47 AM, Florian Rivoal <florian@rivoal.net> wrote:

> Since CSS-UI level 3 is getting increasingly stable and nearing CR,
> I've just started a level 4 draft as a diff spec.
>
> I've started by adding 'user-select', which we had deferred from
> level 3:
>
> http://dev.w3.org/csswg/css-ui-4/#content-selection
>
> There is general agreement between existing implementations about
> which values should exist and what they mean, so I have not tried
> to be creative about that.
>
> However, the interop story is less nice when you look into the
> details, as browsers disagree on the meaning of auto, computed
> values, inheritance, applicability to editable elements...
>
> The specification tries to strike a reasonable middle ground. It
> tries to be close as possible to existing implementations when
> they agree and make sense. When it diverges from some of the
> implementations, I've either included a note saying why, or an
> issue highlighting the disagreements.
>

I'm really happy to see this moving forward!   I'm not an expert on all the
behavior of user-select, but I definitely support changing blink to match
IE and FF in terms of how selections spanning different user-select regions
behave.  In particular, when a drag starts on a 'user-select: none' and
extends to a 'user-select: auto' element, blink/WebKit currently selects it
the text in the 'auto' region.

This has been problematic for us in a number of ways, and (without being
aware of this debate in advance) I just filed a bug for us to try to change
blink to match IE/FF here (http://crbug.com/481985).  In particular, it
means you can get accidental selection when dragging (exasperated by our
recent spec compliance fix to stop paying attention to preventDefault on
mousemove for purposes of selection).  Perhaps more importantly, it makes
it hard to implement text selection efficiently on pages with lots of
user-select: none ranges.  It's easy to reproduce problems in practice [
http://crbug.com/472258] in Chrome and Safari where adding 'body {
-webkit-user-select: none; }' causes mouse dragging to be very expensive,
and this has come up as an issue with, for example, games.

Also, even though as of today, only IE supports the ''element''
> value, I have included it because:
>
> * Even browsers that do not explicitly support it have this
> behavior on editable elements (<input>, <textarea>,
> contenteditable elements...)
>
> * It influences the overall design of the property in terms of
> inheritance and computed values.
>
> * Mozilla[1] and Tab[2] have expressed at least some interest in
> having this value with similar semantics to IE.
>
> Feedback most welcome.
>
>  - Florian
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036853
> [2] https://lists.w3.org/Archives/Public/www-style/2014Nov/0541.html
>
>