Should minimal contentEditable default text input (was: contentEditable=minimal)

Starting a new thread for this specific topic as I think it's one of the 
important early points of contention.

On 22/05/2014 12:59 , Piotr Koszuliński wrote:
> 3. Typing characters. It works in textarea and I think it should work
> out of the box in cE=minimal. Otherwise, cE=minimal will be useless for
> simple cases (mentioned Twitter), because you'll always need a pretty
> complex library to handle text input. Additionally, I don't remember any
> problem with typing characters, so this seems to  work well already in
> cE=true. There's also the IME which scares me, but I don't have any
> experience with it.


I hear your point about essentially making simple things simple, but I 
really want to resist supporting as much built-in behaviour as possible. 
Of course, it's a trade-off, but I think we should strive for the 
smallest possible amount of behaviour. Note that 1) the complexity of 
simple things by and large depends on the quality of the primitives we 
provide and 2) on the interoperability of what is supported. And the 
simpler the functionality, the more easily interoperable.

Inserting text as the default behaviour for text input events has 
implications:

Things get very weird if you support it when you have a caret (i.e. a 
collapsed selection) but not when you have a selection. And a selection 
can have arbitrary endpoints around and into an element. This means that 
typing with an active selection can do more than add some text to a 
node: it can delete or modify elements. Sure enough this can be 
described interoperably, but it does bring us back to issues we dislike.

It also means that the browser needs to handle composition and its 
rendering, which while it is ongoing may produce relatively weird states 
in the DOM.

I agree that the Twitter box is a good very basic example. It basically 
needs:

   1) Words that start with @ or # to be a specific colour.
   2) Links to be a different colour, and to have their characters 
counted as the shortened link rather than the full thing.
   3) Newlines must be taken into account.
   4) Characters beyond 140 are highlighted in red.

I'm ignoring complications with files and the such. In fact, for the 
purpose of our use case it is only useful IMHO to look at how best to 
handle (3) and (4).

I tried to bang together some code that would do the Twitter box, adding 
a few features along the way and documenting assumptions and issues. It 
looks like that (untested, off the top of my head):

     https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html

It looks a bit scary, but if you remove the part that handles excess 
text and the wordy comments, you just get:

 
https://gist.github.com/darobin/8a128f05106d0e02717b#file-like-textarea-html

Granted, that's still a fair bit of boilerplate. But I think we have to 
take into account the following:

   • This is meant to be low-level. I'm happy to make things easier but 
only so long as we don't introduce magic.

   • We can make introduce some convenience methods for the non-obvious 
parts of the boilerplate. Just having Selection.replace(node|text...) or 
something like new Range(sNode, sOffset, eNode, eOffset) would make 
things a lot nicer.

It's likely I've forgotten stuff though (notably paste filtering, which 
I'm unsure how to best handle here — see comments). Please review the 
code so that we have an idea for a baseline of what we'd like to get at 
the end.

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

Received on Friday, 23 May 2014 11:39:53 UTC