[whatwg] Editor types [Was: Pressing Enter in contenteditable: <p> or <br> or <div>?]

On Wed, May 18, 2011 at 8:23 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Wed, May 18, 2011 at 1:40 AM, Markus Ernst <derernst at gmx.ch> wrote:
> >
> > Re-reading the discussions I get the impression that we have actually two
> > different basic concepts of online rich-text editors:
> >
> > 1. A WYSIWYG editor. It offers all kinds of formatting options, allowing
> > users to apply their preferred fonts, colors, sizes, table column widths
> and
> > whatever. In this case I want to generate a code that preserves the
> visuals
> > in all kinds of situations. In this case, it may be a good idea to
> generate
> > style attributes whereever possible. It might even be a good idea to use
> > <div>s for paragraph separation, I don't know.
> >
> > 2. An HTML editor. Authors possibly want to restrict the formatting
> > options. The code generated should be as basic HTML as possible, so the
> > output adapts to the styles of the target page - even if they are changed
> > due to a redesign. In this case I want to avoid style attributes
> whereever
> > possible, and I definitely want to generate <p>s and <br>s. I might even
> > want to make a distinction between <i> and <em>. I assume this is what
> > Ryosuke (and myself) talk about.
> >
> > With this distinction in mind, I think some of Aryeh's questions on what
> > markup we want to generate have two different answers by nature. I read
> > about the styleWithCSS option erlier in this list. Maybe it would be
> helpful
> > to have a more generic option to set the editor into a WYSIWYG or HTML
> > state. This would of course cause more speccing and implementation work,
> but
> > could allow to define two different and consistent sets of standard
> > behaviors.
>
> This is an excellent point but I feel that this is something editor
> frameworks such as TinyMCE and CKEditor should provide.  I'd rather provide
> APIs that let framework easily implement those two modes than adding
> mediocre support in browser.  e.g. being to intercept editing commands such
> as InsertParagraph or Italic and insert an element of choice.


contentEditable is a fine (read: not terrible) API for a WYSIWYG editor.
It's a terrible API for an HTML editor. It is just too high-level to give
useful control over the resultant markup. We should make contentEditable a
good WYSIWYG experience and create new APIs (proposals welcome) for a good
HTML editor. Right now, we're stuck somewhere in between with
contentEditable being both a crappy WYSIWYG editor and a crappy HTML editor.

They are both good use-cases and should be addressed by the web platform.
contentEditable cannot be the solution for both though.

Ojan

Received on Wednesday, 18 May 2011 10:29:45 UTC