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

> On 06 Dec 2014, at 09:43, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> After reading fantasai and Ryosuke's replies, and talking to a few
> people, I changed my opinion to not to define this in CSS UI at least
> in Level 3.
> 
> Currently Editing TF is working on overhauling selection and editing,
> and defining selectability is a bit too hurry. CSS could define how
> selection looks, but as Ryosuke said, I think it's better for the
> selection and editing experts to define and CSS to refer to it.

Right. If we can neither define how it looks nor how it behaves without
referring to specs that haven't been written yet, the benefits of
standardizing it now seem limited to me. Even if we get some high level
description in, we could not go very far when it comes to writing tests.

I am still of the opinion we should put this in level 4, marking the interop
issues explicitly, and taking our time to solve them properly based on
Editing TF's work.

 - Florian

> On Sat, Dec 6, 2014 at 1:10 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>>> On Dec 4, 2014, at 9:07 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>>> 
>>> 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.
>> 
>> This should be defined in either a future version of Clipboard API or Selection API specifications.
>> 
>>> 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.
>> 
>> I'm not sure if there is much value in defining hints in a specification.  If anything, my selection API can either provide a hook CSS spec can refer to.
>> 
>>> 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.
>> 
>> I'm not certain standardizing selection rendering is possible or even desirable.  Various browser engines follow platform conventions to render selection, and it's going to be extremely confusing if we forced all UAs to render selection in a way that doesn't match the underlying platform.
>> 
>> Copying behavior should certainly be defined in WebApps or HTML WGs.
>> 
>>>> 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 Saturday, 6 December 2014 10:52:53 UTC