Re: [css3-ui] bringing back 'user-select' (issue 50)

> On 26 Nov 2014, at 18:54, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Nov 26, 2014 at 8:04 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> https://wiki.csswg.org/spec/css3-ui#issue50
>> 
>> A while back, Tab and Ted have separately suggested since user-select has multiple implementations, it should be included in css-ui (it hasn’t been in a TR document since 2000), but not conclusion was reached as far as I can tell.
>> 
>> I’ve done a bit of testing and documentation digging.
>> 
>> Today, all browsers (IE, Chrome, FF, Safari, webkit-based Opera) support:
>> - none, with the same semantics
>> - text, with the same semantics
>> - auto, which seems to compute to ‘text' in all browsers but FF, where it computes to ‘auto'
>> 
>> There used to be an issue about none and -moz-none meaning different things in firefox, where -moz-none matched what other browsers call none. However, this has been resolved since FF 21, and everybody has the same meaning for none.
>> 
>> Chrome, FF and Safari (but not IE) support ‘all’, with different semantics:
>> - in FF ans Safari, selecting any part of the element selects all the text in the element
>> - in Chrome, it doesn’t seem to do anything obviously different from ’text’.
>> 
>> There also used to be a difference between FF and Safari about the behavior of all (non atomic selection when doing keyboard selection in FF), but as of FF 33, the difference appears to be gone.
>> 
>> IE and FF (but not anyone else) support ‘element’, which doesn’t seem to do anything in FF, and restricts the selection to the element where it started in IE.
>> 
>> The initial value is:
>> - FF: ‘auto’ computing to ‘auto’
>> - IE: ‘auto’ computing to ‘text’ (based on documentation)
>> - webkit/blink: ‘auto’ or ’text' computing to ‘text’ (couldn’t find which)
>> 
>> Also, FF hides this property from getComputedStyle. Other browsers don’t do that.
>> 
>> The two main issues since this was last discussed (‘none' and ‘all' having non interoperable behaviors between gecko and webkit) appear to have been resolved. Even then, there are issues left to work out. This doesn’t really seem ready for inclusion in a spec trying to make it to (and through) CR, so I would like to reject inclusion in level 3.
>> 
>> We can probably bring it back at level 4, at least with a restricted subset (none, text, maybe auto, maybe all), although personally, I am far from sure this is even a good idea at all, as messing with and/or disabling selection sounds quite user-hostile.
> 
> We can do "none" and "text" interoperably; there's no reason not to
> spec that today in UI 3.  "all" also seems reasonable; you have two
> implementations that agree, one that appears to just recognize the
> keyword but doesn't actually implement it, and one that doesn't
> implement it.  That seems to be enough consensus to be worth speccing
> it.  Same with "element" - two implementations agree, and two don't
> have it.

If we want to push it ahead with just ‘none’ and ‘text’, the initial value cannot be ‘auto’, which is currently the case at least in IE and FF (and maybe blink and webkit, but I can’t tell without reading the source because ‘auto’ might compute to ’text’). If you want to include ‘auto’, we need to define what it means and what it computes to.

If you want to include ‘all’, I’d like to know what it means in chrome before standardising something else. It doesn’t seem to do anything other than text, but I might be missing something.

Same with ‘element’. Firefox has it, but it doesn’t seem to do anything obvious.

Finally, are we sure this is really a good idea?

 - Florian

Received on Wednesday, 26 November 2014 18:10:34 UTC