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

> On 28 Apr 2015, at 19:52, Rick Byers <rbyers@chromium.org> wrote:
> 
> On Thu, Apr 2, 2015 at 10:47 AM, Florian Rivoal <florian@rivoal.net <mailto: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 <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 <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 <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.

Thanks for the feedback, and good to hear that we're headed towards more convergence in behavior.

As you noted, I had captured some of the differences between the various browsers in the spec issues, but the specific difference you pointed out wasn't explicitly mentioned, so I've updated the issue to call it out as well.

If you notice more differences either between various browsers' implementations, or between implementations and the spec, please let me know so that I can list up everything explicitely in the spec. It's much easier to resolve issue when we're aware of them.

 - Florian