[whatwg] What exactly is contentEditable for?

[Lachlan Hunt]

Ian Hickson wrote:
>>Although I am against the use of contentEditable in general, that's 
>>mostly because {a) all the implementations of it are broken
> 
> All the implementations of CSS and HTML and the DOM are broken too, I 
> don't suggest we remove those! :-)

That's true, but they can be fixed.  contentEditable may be able to be 
fixed one day too, if it were well defined, standardised and 
implemented.  However, even if the impelemtnations weren't broken, it 
still suffers from the following problems...

>>and (b) the way it was designed is too presentationally oriented for a 
>>semantic markup language - it basically suffers from the same design 
>>flaws as every other WYSIWYG editor.
> 
> Could you elaborate? It would be nice to fix these.

I'll do my best to summarise the core problems.

Most (if not all) WYSIWYG editors don't cleanly seperate the editing of 
content and of presentation.  Users are able to enter text and then 
directly speficify how that text should look, often through toolbar 
options like font family, font size, bold, italic, underline, colour, 
background, border, etc.  If you open up any WYSIWYG editor or word 
processor, the chances are that you'll find most of those options 
available on one of the standard toolbars.

Although some editors do also provide some semantic options, they're 
usually limited in their abilities.  Some have some semantic block level 
elements like headings, paragraphs, lists and maybe blockquote. 
However, few have semantic elements like abbr, cite, code, dfn, kbd, 
samp, var, q and strong/em (some, like contentEditable, mistakenly use 
bold and italic options for those).  I often have to jump through hoops 
just to get <code> in my markup while using dreamweaver, by using the 
buttons for <b> and/or <i> and then running search and replace to fix up 
the markup.

Additionally, even fewer WYSIWYG editors allow authors to easily 
categorise (or class) semantic elements easily.  As a user, I should be 
able to, for example, mark up a note by first selecting a paragraph and 
then saying that it belongs in the "note" class.  I know of no way to do 
so with contentEditable and I haven't found an easy way to do so with an 
editor like dreamweaver, short of editing the markup directly.

>>Personally, I'd like to see it better integrated with the DOM 2 Range 
>>interface, so the scripts could work with the nodes a little easier and 
>>which I'd like to see more widely implemented.
> 
> Could you elaborate?

I'll try, though my experience with DOM range is limited since it's not 
widely implemented.

For example: Adding a new element around content should be done somewhat 
like this:

var selection = ... // Assume this is set to the Range selected by the
                     // user
selection.surroundContents(document.createElement("code"));

That's far more extensible than using the execCommand() method, which 
requires the commandIdentifier to be know for each element it an insert, 
and for which there is no command I know of for adding a code element. 
If DOMRange were used, then contentEditable may become usable for 
non-HTML languages and even with new elements added to HTML.  Correct me 
if I'm wrong, but I don't believe it can be used for that, the way it's 
been designed and implemented.

-- 
Lachlan Hunt
http://lachy.id.au/