Re: contentEditable=minimal

Great news and a great idea. I totally second a concept of making
contenteditable simpler and a lot more controllable for us, editors
developers. Even if it would be possible to make cE=true interoperable,
there are cases which depend on editor's logic. For example, in CKEditor
Bold command may be totally blocked depending on content filter settings
(you should not be able to create disallowed content). Similarly, enter,
backspace/delete, end/home, undo&redo, arrow keys, most of CTRL+
keystrokes, context menu, click->select - we already control them totally
or at least in specific cases. And even if related features would become
reliably stable, many times their behaviour should depend on editor's
logic, configuration, and a use case in which editor is used. That's why a
standard and reliable way to intercept them will be very helpful.

Moreover, I understand very well how hard and time consuming maintaining cE
implementation is. And currently we have 4 implementations - one in every
browser engine. Then editors developers override significant amount of that
work. This doesn't make sense. It would be beneficial for everyone if
browser vendors could focus on the necessary minimum and editors developers
on creating an editing framework and specific solutions on top of that. The
frameworks would be something like jQuery for editable. They would simplify
most common tasks, like applying Bold/Italic/etc styles, inserting HTML
into selection, filtering, supporting enter key, etc. All of these
operations are very complex and require rare knowledge about cE, selection,
ranges and deep understanding of DOM.

I was trying to imagine what cE=minimal would be then. CE=true pretends to
be an entire WYSIWYG, from which you need to subtract the things which you
don't like. CE=minimal could be the opposite - a textarea-like field. You
would add your features to it rather than subtract from it. What's more,
for some really basic use cases, like Twitter's "compose tweet" box, it
would be a sufficient base without much additional code.

## What should cE=minimal handle?

1. Selection and caret drawing.
2. Selection API - I know that this is a separate topic, but in order to
make building features on top of cE=minimal acceptably hard (and not
extremely hard), the selection must be improved. I.e. selection in empty
inline elements, selection in empty blocks, selection of non-editable
(cE=false) content and nested editables, bogus <br>s, selection in tables,
selection in multiple frames, etc. All those things are broken now.
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.
4. Delete, backspace. Here I've got more doubts, because it's now broken in
some engines (merging blocks, deleting inline elements, possibility to
leave paragraph, etc.). But without native support for them cE=minimal
requires JS implementation of them, and taking CTRL modifier into
consideration, the implementation becomes big. So I think that delete and
backspace should also work out of the box, but should implement the
simplest possible algorithm, sufficient to work with paragraphs of text
(Twitter case again). But their behaviour in lists, tables may be
simplified, so the algorithm is generic and may not be good in terms of UX.
That would be customised by editors that need tables and lists and other
fancy features. Note: typing on a non-empty selection may trigger delete
event + type event afterwards, so customising delete will customise typing.
5. Navigating with arrow keys, selection with SHIFT, CTRL modifier. Again,
works in textarea, should work in cE=minimal. Additionally, implementing
up/down keys in JavaScript seems to be extremely hard at the moment.
6. Spell check. When you want a native spell check you cannot override
context menu. When you want custom context menu, you need custom spell
check (which is extremely hard). And context menu is very important for
many users because they used to look there for contextual options, so most
editors override it. Therefore, a way control at least one of them (I guess
it won't be a context menu, though that would be awesome) will be great.

## What should not be handled by cE=minimal?

1. Bold, italic, list, link, blockquote and other commands creating
content. All of them are not crucial for simple cE=minimal use cases.
Additionally, it's controversial whether <b> or <strong>, <em> or <i>,
there are many ways how lists and blockquotes can be created out of
selected contents, etc. You end up rewriting all of them if you need them
in your editor. Therefore, I think it makes sense to not waste time trying
to standardise them and then fix implementations. Those features can be
implemented by the editing framework.
2. Enter key support. My biggest doubt, but I finally put it in this
section. In most basic use cases enter key support is not needed at all and
in all other it must be overwritten. It rarely works as you would expect
and it's pretty easy to implement it in JavaScript for simple use cases.
3. Tables and images resizing. Buggy in these engines which implemented
that, missing in others. And totally uncontrollable.
4. Another thing that browser engines cannot do is trying to be... too
smart? Guess what will happen if you press backspace and then letter in
<strong>x^</strong>. You will have <b>l^</b>. In <a href="">x^</a>? You'll
end up with <u>l^</u> (I love this case!). What's more, after you press
backspace, there's no way to tell that engine will recreate inline element,
because element is removed at that point, so the state is kept in engine
internals. What I'm trying to say is that the state in cE=minimal should be
clear - if an information cannot be retrieved from selection API and DOM,
it does not exist.
5. There should be no native toolbars in cE=minimal (and other native UI
interfering) like the one Safari opens on iOS if you have non-empty
selection.

## Not sure about:

1. Pasting, dropping. It's a similar case to enter key, because most
editors have to intercept all that. What some engines paste now is
unacceptable, inserted content has to be filtered according to editor's
setting and for example DnD of block contents should be handled differently
than inline contents. However, without pasting and drop support the idea of
cE=minimal behaving like textarea won't work - it has to work even in the
most basic cases. Intercepting the paste/drop event is easy, but then HTML
insertion is less trivial. So if there will be a reliable command or
method, then I think it does not have to implemented by cE=minimal. BTW.
Developers would also be very glad if browsers were keeping only semantic
data in clipboards, not bazillions of spans with inline styles from which
it's very hard to do anything reasonable even when handling paste manually.

## To sum up.

I see cE=minimal as an implementation of textarea's features in any DOM
element. It should be as minimal as possible, meaning that features you
would not expect from textarea should not be implemented in cE=minimal. At
the same time features required for basic usage (like the "compose tweet"
box on Twitter) should work out of the box if their JavaScript
implementation is hard.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer