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

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

From: Koji Ishii <kojiishi@gmail.com>
Date: Thu, 4 Dec 2014 23:07:03 +0900
Message-ID: <CAN9ydbU3Tsm7q3w5kLcM7Ea93q+M5Sf4z6x1NksuAm9TQCupGw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC