RE: contentEditable=minimal

> From: Robin Berjon [mailto:robin@w3.org]
> 
> On 23/05/2014 11:55 , Jonas Sicking wrote:
> > On Thu, May 22, 2014 at 3:59 AM, Piotr Koszuliński
> >> 5. Navigating with arrow keys, selection with SHIFT, CTRL modifier.
> >
> > Agreed. Developers have to deal with selection moving around anyway
> > since they should handle touch screens.
> 
> 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.

> > But we should definitely fire events whenever cursor or selection is
> > moved and enable the page to either cancel the movement, or adjust the
> > location before it takes effect.
> 
> Agreed. I also think that it is important that if the selection is allowed to have
> anchors both inside and outside the editing area then the editing MUST NOT
> retain focus. Anything else would lead to really annoying cases.
> 
> Note: you keep saying things like "cursor or selection". Can we agree that
> they are the same thing? A caret on its own is a selection with a single
> collapsed range (and a direction).

Yes please:) Cursor and selection are the same thing.
 
> > I think there might be a lot of boiler plate needed to implement
> > plaintext editing. Not only are there normal "beforeinput" events to
> > take into account. There's also things like composition events,
> > backspace vs. delete, modifier+backspace/delete (deleting a
> > word/line), voice-to-text input (provides data word-by-word), pasting,
> > (bidi?), etc. It adds up pretty quickly.
> 
> 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). 
 
-Ben

Received on Tuesday, 27 May 2014 00:08:14 UTC