Re: contentEditable=minimal

On 22/05/2014 10:52 , Jonas Sicking wrote:
> This sounds like a super promising approach.

\o/

> If I understand the proposal correctly, when the user does something
> that causes input, like pressing the enter key, we would fire a key
> event, but we wouldn't actually modify the DOM. Modifying the DOM
> would be the responsibility of the web page.

That is the point yes. Using the DOM as both the model and view does not 
make sense for all editing, and this makes it possible to separate the 
two without hacks that override the browser.

Your example of the enter key is, of course, one of the annoying ones. 
Sometimes you want a new line, sometimes you want the next element, 
sometimes you just want to navigate to the cell below.

Enter may be a case in which a higher-level event is required so that 
you can respect the platform's convention for Enter vs Ctrl-Enter for 
instance.

> Likewise, if the user pressed whatever key is platform convention for
> "paste", we would fire an event which contains the clipboard data, but
> not mutate the DOM. Copying data from the event (i.e. from the
> clipboard) to the page would be the responsibility of the page.
>
> Is that correct? If so I like it a lot!

Entirely correct. Again, \o/.

> I'd like to expand, and clarify, the list of services that you propose
> that the UA provides:
>
> * Caret and selection drawing.

Yes. And reporting that information accurately to the application (which 
can be pretty tricky for multi-range selections in tables or at bidi 
boundaries).

cE=minimal enables caret drawing, the rest is done through the Selection 
API.

> * Drawing IME UI in response to user typing.

Where applicable, yes. I would expect the IME API to play well here.

> * Events for clipboard and drag'n'drop (though the UA would not mutate
> the DOM in response to those events).

Yes. ClipOps and DnD APIs.

> * Cursor navigation, including reacting to touch events, mouse clicks
> and keyboard events. Cursor navigation would likely also fire
> cancelable events.

Yes. Cursor navigation can be represented through selections (that may 
be collapsed). In general it is important that selection changes can be 
cancelled so that developers can carry out selection validation before 
accepting it.

Making some things unselectable might also be useful. IE has 
unselectable, there's also -moz-user-select and friends. But this is 
small fries for later I'd reckon.

> * Turning keyboard events into events representing text input (but not
> mutate the DOM in response to those events).

Yes, possibly in a rather advanced manner.

> * The Selection API spec for selection manipulation.

Right.

> Can we simply use the same events as we fire in <input type=text> and
> <textarea>, but don't actually mutate any DOM? Or is it awkward to
> fire "beforeinput" when there is no default action of mutating the DOM
> and firing "input"?

Isn't that just a question of whether to reuse the same event name or 
pick a new one?

> And is it too much complexity to ask pages to deal with composition
> handling themselves?

I think it's too much to ask for them to deal with composition, but they 
should deal with composition events. See my earlier posts for details.

Dealing with composition events is certainly a bit of effort (not much 
though — the hardest part is knowing they exist) but we want to go 
low-level here. I think it's an acceptable level of complexity for 
library authors.

> Another approach would be to allow plain text input events to actually
> mutate the DOM as a default action. But allow that action to be
> cancelled. Note that we would never do anything more complex than
> mutate an existing text node, or insert a text node where the cursor
> is located. I.e. no elements would ever get added, removed, split,
> have attributes changed or otherwise be mutated.

I don't think you can do that without ending up weird places. "No 
elements would ever get mutated" -> what happens if I have a selection 
that contains an element (or parts of it)? Very quickly you'd end up 
either having to make the browser manipulate the DOM yourself (bad, 
really really bad), or in a situation in which some text events have a 
default action and some don't depending on the current state of the 
selection (possibly even worse).

It's very tempting to try to "do more" for developer here, but I really 
think we should resist this impulse lest we end up with the a new mess 
that just works differently.

> But if we can make the code that a page needs to write in order to
> handle the text mutation relatively simple, even when handling
> composition, then I think we should leave it up to the page.

I think that we can make it reasonably easy to handle composition by 
using composition events.

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

Received on Thursday, 22 May 2014 14:27:03 UTC