@contenteditable versus <richtext>

Here is a pretty full list of @contenteditable based WYSIWYG editors:
http://www.geniisoft.com/showcase.nsf/WebEditors

If you take a look through the list you will find that almost all of 
them designed to edit only HTML fragments and not a full page editors.

Pure content WYSIWYG editors are used in:
  - blog (article) editors;
  - wiki and other forms of CMS;
  - online e-mail clients;

These use cases cover 80%-95% of all WYSIWYG editing needs. So I think 
it makes sense to introduce special input element <richtext> or 
<htmlarea> rather than trying to define undefineable that appears to be 
  that @contenteditable (as a UI mode) and its interaction with scripts 
and styles.

I see such <richtext> as an input element with API simple as possible:

<richtext attributes>
   ...initial html content...
</richtext>

There are just two attributes:

  - tools="id"

    is an ID of toolbar - element that contains buttons like
    "B", "I", "H1", "H2", etc. These buttons are bound to internal
    "registers" of the editor and styleable by the author of the
    host page. Such toolbar binding shall not require scripting to
    operate. Binding can be made by using @command attribute of
    tool[bar] buttons. See example below.

  - content-styles="url.css"

    is an url of style sheet that contains list of style
    declarations. This list contains only simple "tag" selectors
    and is used for:
     a) styling the editing content;
     b) definition of HTML elements that are allowed to be used
        in this instance of the editor.


Sample ------------------------

(close to) real life sample:

<div #tools>
   <button command="richtext:undo"><img/></button>
   ...
   <button command="richtext:paste"><img/></button>

   <button command="richtext:strong"><img/></button>
   ...
   <button command="richtext:h1"><img/></button>
   ...
   <button command="richtext:h6"><img/></button>
</div>

<richtext tools=#tools>
    <p>Hello World</p>
</richtext>

We can define minimal list of commands that conforming UA
shall support plus optional extended set.

flat DOM --------------------------

Such <richtext> shall use so called "flat DOM" so
there cannot be:
  1) nested <div>s;
  2) <li> is a kind of <p> - can contain only text and spans.
  3) nested tables;
  4) only two levels of spans are allowed - so called
     background and foreground spans;
  5) there are no <font> and <span> elements inside the editor.

content submission -----------------------

Richtext submits data as html text in the same way as <textarea>.

I think that the <richtext> shall allow <img/> to be inserted
in the document from clipboard (from local machine).
Submission of such images shall be done together with document.
I am thinking either about special <data> container that have named 
<item>s with base64 encoded image data or by using <img src="data:..">.

----------------------------

Goal is to have input element that can handle "as-is" major number of 
cases and is easy to use by developers and by user.

---
Andrew Fedoniouk.
http://terrainformatica.com

Received on Wednesday, 10 October 2007 06:32:44 UTC