Re: contentEditable=minimal

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?

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.



On Mon, May 12, 2014 at 9:26 AM, Robin Berjon <robin@w3.org> wrote:

> On 12/05/2014 00:46 , Johannes Wilm wrote:
>
>> Also this looks good. There seems to be consensus that contenteditable
>> is just not going o get fixed, and so removing the faulty behavior
>> entirely and replacing it with this would be almost as good.
>>
>
> It depends on what you mean by "fixed". It is conceivable that given
> enough time and energy the current contentEditable behaviour could be made
> interoperable, but the problem is that even if that happened it seems clear
> from developers' feedback that it wouldn't do what they want. A lot of the
> time you would still want to disable a lot of what it does by default and
> handle it yourself. This is therefore just intended as a way of providing
> developers with primitives for editing.
>
>
>  Intercepting key strokes is already now possible and probably the best
>> one can do. The one thing where this gets complicated is when typing
>> characters using more than one key stroke. such as ~ + n to make ñ. I am
>> not sure if you include that under the "Some keyboard input handling".
>>
>
> Yes, text input is a hard problem and you can't get away without solving
> it. We are talking about providing primitives here, so things can be
> expected to be a little bit hairy though.
>
> DOM 3 Events has something called composition events for the example you
> bring up (which can get a whole lot more complicated, notably with things
> like Kotoeri and such). On the face of it it would seem to be the needed
> part but I've never used them (or seen them used) in the real world. (The
> quality of browser support is also unclear at this point.) Some cases also
> require the IME API.
>
> Developers relying on the bare bones cE would probably have to handle the
> rendering of ongoing composition themselves (which isn't the end of the
> world, but you need to think about it or you are guaranteed to mess things
> up). This is probably acceptable at this level, libraries can make it
> easier.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>