Re: [editing] Leading with ContentEditable=Minimal

On Jun 29, 2014, at 10:22 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:

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

This is a great concrete use case.

On Jun 26, 2014, at 3:24 PM, 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.

I don't think we can set a goal without first enumerating use cases and the problem we're trying to solve. 

> Use Cases:
> * Create a js framework that enables a WYSIWYG editor and works the same in all browsers with little browser-specific code

This one is a bit vague as a use case.  Are you thinking of a WYSIWYG editor you see on CMS or a blog editor?  Or does it include something like EitherPad?  I think we need to be much more concrete.

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

Could you elaborate on the use case of making such an editor?  e.g. allowing only certain types of styling in comments.

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

Could you elaborate on how non-editable content appears/used inside an editable content?

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

These are great use cases.

I'd throw in two more:
Web-based DTP application: The app can creates a document that contains pagination, columns, and a complex illustrations.  It needs to let users edit any text that appears in the document.  Each editable text needs to be accessible, and styles applied to text need to be backed by the application's internal model of the document.
Semantic HTML WYSIWYG editor for a blogging platform: The editor needs to able to add both semantic and visual annotation to the document as it will be published as a blog.  Headings are to be marked up with h1. h2, etc... and each acronyms, abbreviations, and so forth are marked up with respective HTML elements.  However, the editor also supports visual annotations such as bolding, italicizing, and enlarging text, each of which will be interpreted by the editor to respective underlying semantics in HTML.


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


Thanks for a great list of use cases.  Now we need a required set of features/API for each use case.  We can then evaluate whether what has been discussed thus far satisfy enough use cases or not.

- R. Niwa