Re: [editing] Leading with ContentEditable=Minimal

Another use case: Create a track changes function within an editor (like
https://github.com/NYTimes/ice ) that really should be run MVC in order to
keep the code somewhat readable. Currently ICE breaks whenever any of the
browser makers decide to change anything about contenteditable.


On Fri, Jun 27, 2014 at 12:24 AM, Olivier F <teleclimber@gmail.com> wrote:

> 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.
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com