Re: [editing] Leading with ContentEditable=Minimal

On Thu, Jun 26, 2014 at 3:51 AM, Robin Berjon <robin@w3.org> wrote:

> On 24/06/2014 20:09 , Ben Peters wrote:
>
>> Problems:
>> * ContentEditable is too complex and buggy to be usable as-is
>> * ContentEditable does not easily enable the wide range of editing
>> scenarios
>>
>
> Complex and buggy aren't necessarily show-stoppers. With hard work it
> should be possible to take the current Editing APIs draft and progressively
> iron out most of the kinks. It's difficult, but difficult things have been
> done before.
>
> The main problem here is that even if we did that we still wouldn't have a
> usable system. And I would say that the issue isn't so much that it doesn't
> enable scenarios more than that it works actively hard to make them hard to
> implement :)
>
> Maybe this can be captured as "Does not support
> http://extensiblewebmanifesto.org/".
>
> I agree with this. The problem is not complexity. I don't expect
implementing a well-appointed custom content editor will be anything but
complex.

The problem is that contenteditable=true is a high-level API which by
definition has to assume a lot and do a lot. This prevents custom behavior
from being implemented without clashing with the "helpful" high level
behavior that the UA is expected to do.

Our goal should be to provide a set of low-level building blocks for
text/content editing. I think that with cursor=true, and commandEvents, and
improved Selection API we're headed in the right direction.

>
>
>  Use Cases:
>> * Create a js framework that enables a WYSIWYG editor and works the same
>> in all browsers with little browser-specific code
>>
>
> s/little/no/ ;-)
>
>
>  * Use a js framework to insert a customized editor into an email client
>> * Use a js framework to insert a customized editor into a blog
>> * Use a js framework to insert a customized editor into a wiki
>>
>
> Aren't those the same as the previous one?


I agree these all seem the same. Here are a few other use cases I can think
of:

* Create a web-based structured content editor, where the allowable DOM
elements and/or classes in the content are pre-defined.
* A complete book/whatever editor, which can contain areas of non-editable
content, nested editable content, etc... See fiduswriter.org, and what
CKEditor are doing with widgets.
* Browser-based code editor. Currently CodeMirror and others go through
amazing lengths to provide something that looks and behaves like a desktop
code editor.
* Browser based "word art" generator where end-user types some text and it
renders in 3D along a curve and in rainbow colors on a <canvas>.

I picked these examples because they illustrate why separate building
blocks are the right way to go. I would expect the developer of the
structured content editor to leverage cursor=true, commandEvents and
Selections API, and if it's available some sort of text insert mechanism.
In contrast the "word art" developer would only leverage commandEvents and
will have to draw their own cursor and selections along with their fancy
curved 3D text.