- From: Koji Ishii <kojiishi@gmail.com>
- Date: Thu, 4 Dec 2014 23:07:03 +0900
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Mats Palmgren <mats@mozilla.com>, www-style list <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Edward O'Connor" <eoconnor@apple.com>, "L. David Baron" <dbaron@dbaron.org>, rniwa@apple.com
Hmm, that's a good point. Although I also like the user-select property included in CSS UI, I'm not sure how much details the spec should define. First, I would like the spec not to require either single or multi-range selections. That should belong to Selection API, which currently require single range (see this note[1]). What you observed on Chrome showing discontinuous selections is actually a single range selection with the mid-part not displayed to look like a selection, so it's an issue of rendering of selections. The behaviour of copying to clipboard is yet another possible spec item. It's quite impossible to spec the copy behaviour because it's too complex, but it may be possible to write a spec that suggests whether an element should be included to copy by CSS property values, such as display or user-select. If we want to do that, since it's a cross-WG item, I'm not sure which WG/spec it should go. So, while the property might need to be defined in CSS UI, I think it's scope needs to be determined. My preference is that CSS UI defines hints for selections, and the precise selection behaviour should be in WebApps WG or left UA dependent. Regarding the rendering and copying, I don't have strong preferences, but the first thing we should discuss is whether it should be included in CSS UI, in other WG/spec, or not to be defined. [1] http://w3c.github.io/selection-api/#h_note_15 /koji On Wed, Dec 3, 2014 at 9:14 AM, Florian Rivoal <florian@rivoal.net> wrote: > >> On 26 Nov 2014, at 20:14, Mats Palmgren <mats@mozilla.com> wrote: >> >> On 11/26/2014 04:04 PM, Florian Rivoal wrote: >>> 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. >> >> Fwiw, we're leaning towards implementing IE's behavior for 'element' >> in Gecko: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1036853 > > Ok, so there seems to be interest in the spec and in implementations. Maybe we can revive it for level 3 after all if the interop issues can be sorted out quickly. If not, this should still be specced, but I’d still go for level 4. > > I still need a description for what the auto value is supposed to mean, if that’s the one used for the initial value, and agree on what it computes to. > >> (Thanks for sorting out the interoperability issues here, btw. >> It's much appreciated.) > > Found one more interop problem. If you use this markup (properly prefixed): > <div> foo <span style=“user-select:none”>bar</span> baz</div> > > In Firefox, while it is not possible to start the selection in the span, if you start in the selection in foo and end in baz (or do ctrl+a), Gecko will highlight bar as well. But you’ll only get “foo baz” into the clipboard if you copy. > > Chrome and Safari will do the opposite, and show a 2-piece discontinuous selection (highlighting foo and baz but not bar), but copying to the clipboard gives “foo bar baz” > > IE will both let you highlight "foo bar baz” and put “foo bar baz” in your clipboard, only disallowing selections that start in "bar”. > > - Florian
Received on Thursday, 4 December 2014 14:07:30 UTC