- From: Robin Berjon <robin@w3.org>
- Date: Fri, 06 Jun 2014 15:42:19 +0200
- To: Ben Peters <Ben.Peters@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Piotr Koszuliński <p.koszulinski@cksource.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 02/06/2014 23:01 , Ben Peters wrote:
>> From: Robin Berjon [mailto:robin@w3.org] I think that the latter is
>> better because it gives the library the computed range that matches
>> the operation, which as far as I can imagine is what you actually
>> want to check (e.g. check that the newRange does not contain
>> something unselectable, isn't outside a given boundary, etc.).
>>
>> The former requires getting a lot of details right in the spec, and
>> those would become hard to handle at the script level. On some
>> platforms a triple click (or some key binding) can select the whole
>> line. This not only means that you need direction: "both" but also
>> that the script needs a notion of line that it has no access to
>> (unless the Selection API grants it). What makes up a "word" as a
>> step also varies a lot (e.g. I tend to get confused by what Office
>> apps think a word is as it doesn't match the platform's idea) and
>> there can be interesting interactions with language (e.g. is
>> "passive-aggressive" one word or two? What about "co-operation"?).
>>
>> But maybe you have a use case for providing the information in that
>> way that I am not thinking of?
>
> This seems like it's getting pretty close to the browser just doing
> the selection. A browser would still have to figure out what the
> selection should look like in the version you suggest. Instead, maybe
> each site could decide what is thinks is a word ("passive" or
> "passive-agressive"). The line example is good, so maybe we should
> have a 'line' level selection just like the 'word' level?
Yes, the way I see it the browser *always* figures out what the
selection is; but the developer gets a chance to cancel (or modify) it.
> Yes my understanding is that today you get both. I'm not arguing
> against that as the events stand today, but when we talk about
> 'Intention Events' as an abstract type with certain properties like
> commandName, I think you should only get one of those (paste or
> command or beforeinput), and I'm suggesting that it should be paste
> in this case.
Agreed, that's sanity.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 6 June 2014 13:42:31 UTC