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

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.

I don't see any good reason to delay this property.

~TJ

Received on Wednesday, 26 November 2014 17:55:42 UTC