Re: contentEditable=minimal

Hi Ben,

On 27/05/2014 02:07 , Ben Peters wrote:
>> From: Robin Berjon [mailto:robin@w3.org] Even without accounting
>> for touch screens, you really want the platform to be the thing
>> that knows what Ctrl-Shift-Left means so you don't have to support
>> it yourself (and get it wrong often).
>
> Agree. One way to do this would be BeforeSelectionChange having a
> commandType indicating select forward and select by word.

I think we agree at the high level but might disagree over smaller
details. You seem to want something that would roughly resemble the
following:

BeforeSelectionChange
{
   direction:  "forward"
, step:       "word"
}

whereas I would see something capturing information more along those lines:

BeforeSelectionChange
{
   oldRange:  [startNode, startOffset, endNode, endOffset]
, newRange:  [startNode, startOffset, endNode, endOffset]
}

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?

>> Not all of those are separate, though. Voice input is just an input
>> (or beforeinput) that's more than one character long. There's
>> nothing wrong with that. So is pasting (though you need cleaning
>> up). Composition you need to handle, but I would really, really
>> hope that the platform gives you a delete event with a range that
>> matches what it is expected to delete rather than have you support
>> all the modifiers (which you'll get wrong for the user as they are
>> platform specific). As seen in the code gist I posted, given such a
>> delete event the scripting is pretty simple.
>
> I agree, except that I don't know why we want paste to fire two
> 'intention' events (paste and input). Seems like we should make it
> clear that the intention is insert text (type, voice, whatever),
> remove text (delete, including what text to remove), or paste (so you
> can clean it up).

I don't think we want to fire both paste and input, but if my reading is 
correct that is the case today (or expected to be — this isn't exactly 
an area of high interop).

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 27 May 2014 08:49:29 UTC