W3C home > Mailing lists > Public > www-style@w3.org > November 2014

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 26 Nov 2014 17:04:30 +0100
Message-Id: <9AE0BCB2-9D31-41E3-A868-DA3B272659C0@rivoal.net>
Cc: Tantek Çelik <tantek@cs.stanford.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <eoconnor@apple.com>
To: www-style list <www-style@w3.org>

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.

 - Florian
Received on Wednesday, 26 November 2014 16:05:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:49 UTC