Re: contentEditable=minimal

On 22/05/2014 00:43 , Julie Parent wrote:
> I question whether contentEditable=minimal should actually handle text
> input.  If the idea is to provide the base platform on which a developer
> can build the editing product of their dreams, isn't text insertion just
> another behavior they could potentially need to disable?

Sorry if I was unclear. When I said handling text input, I did not mean 
text insertion. My point is that there's a spectrum of behaviour and we 
want to provide *some* handling for developers (otherwise it's really 
just too hard).

Let us take the relatively simple issue with typing "ñ" on a keyboard 
setup that does not natively support the character. On my keyboard, that 
is done by first typing Alt-N, then N.

At the more complete end of the spectrum, what we have today, without 
the developer doing anything, when I type Alt-N the DOM is modified to 
include a U+02DC SMALL TILDE (note: *not* U+0303 COMBINING TILDE) and 
that character is underlined in the rendering to let me know that it is 
awaiting a character to combine with. Interestingly, that information is 
not reflected in the DOM — I don't even know how you can handle it. In 
fact, editors that try to take over too much from the platform (in this 
case, Substance for instance) completely fail to allow this sort of text 
entry.

At completely the other end of the spectrum (more or where developers 
find themselves today when they override as much as they can, out in the 
cold), all you get are two entirely independent keyboard events: one N 
with altKey set to true, and another N with altKey set to false.

Unless you know all platform conventions (plus the user's keyboard 
layout) or you manage to enforce your own, which isn't friendly to 
users, you can't do anything useful with that.

What I meant by having the browser handle text input, is that it needs 
to know the platform conventions so as to convey user intent to to the 
application correctly. When I hit Alt-N then N, the UA should relay 
something that looks like the following events (I'm deliberately not 
including keyup/down/etc. for simplicity):

compositionstart \u0303 (combining tilde)
compositionupdate ñ
compositionend ñ

(We might be able to do without the compositionupdate in this case, I'm 
including it because for more elaborate compositions it's needed.)

I believe that this provides the appropriate level of abstraction to 
address the use case. Without the composition events (e.g. if you only 
send a text input event) the developer can't show the composition in 
progress to the user (which for complex compositions like Kotoeri is a 
non-starter); and with these events developers don't need to know about 
the platform's conventions for composition. Orthogonality is where it 
should be.

As I said I am unsure that the way in which composition events are 
described in DOM 3 Events is perfect, but that's only because I haven't 
used them in anger and they aren't supported much.

> Stepping back, there are distinct concepts that all combine to form the
> current editing environment:
>
>  1. Selections: Enable selections, perform cursor movement, scoping the
>     boundaries on which the selection can operate.
>  2. Input: Perform dom modifications, dispatch events, not limited to
>     keyboard input, also includes IME, paste, drop, etc.
>  3. Spell check: Enable spell check, modify the dom (or dispatch an
>     event) when the user selects a replacement
>  4. Formatting magic: bold when the user hits control + b, change
>     directionality on Ctrl+LeftShift , etc.
>
> It sounds like contentEditable=minimal as proposed would only enable #1
> and #2, and perhaps allow for #3? To break editing down into true
> building blocks, I think we need to provide developers a way to
> explicitly enable each of these systems separably, and not require the
> element to be contentEditable.

My understanding (but this is all up for discussion, hence this thread) 
is that cE=minimal would only enable 1 (which is essentially enabling 
cursor as selections are already there anyway). All the other parts are 
handled by other pieces of functionality that may work elsewhere too 
(and in fact do, e.g. in input elements).

The way I thought of cE=minimal when I pitched it at the Extensible Web 
Summit was basically "regular HTML with a caret affordance". The exact 
behaviour of the caret is platform dependent (and may not be visual), it 
is only the way in which it is reported (in terms of the Selection API) 
to the application that matters.

It makes for a pretty short spec — the previous paragraph is more than 
enough ;)


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

Received on Thursday, 22 May 2014 13:52:23 UTC