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

On Tue, Apr 28, 2015 at 5:16 PM, Florian Rivoal <florian@rivoal.net> wrote:

>
> 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>
> 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.
>
>
> 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.
>

Looks great, thanks!


> 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
>
>