[whatwg] What exactly is contentEditable for?

[Lachlan Hunt]

Ian Hickson wrote:
> On Mon, 15 Aug 2005, Lachlan Hunt wrote:
> 
>>How is [contentEditable] any different from a text area form control 
>>with a specified accept type of text/html, which would allow a UA to 
>>load any external editor (eg. XStandard) or degrade to a regular text 
>>area?
> 
> contentEditable is implemented. <textarea type="text/html"> is not.

And, as I demonstrated in an earlier e-mail with the widgEditor I linked 
to, it's not hard for an author to provide a script that converts the 
textarea to a WYSIWYG editor using the contentEditable DOM interface. 
It's not much different from the scripts that are being written to add 
support for other extensions in today's browsers.

>>That would be a far better option than using contentEditable, which is 
>>not only conceptually broken, but *all* implementations of it are so 
>>incredibly broken, that trying to standardise it is like dragging a dead 
>>horse through mud.
> 
> There may be some truth to that, but contentEditable also has other 
> benefits, like integration with the DOM, and the ability to seemlessly 
> integrate with the page. For example, on a wiki, you can be browing the 
> content, and then toggle one area so it is contentEditable, edit it, and 
> submit that, all asynchronously and without having to switch in a 
> <textarea> or anything like that.

That's a reasonable argument for standardising the DOM interface for it, 
but not for including contentEditable as an attribute in the markup, 
which is what I'm against the most.

Although I am against the use of contentEditable in general, that's 
mostly because {a) all the implementations of it are broken 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.

Using the wiki example, a script could be provided which captures the 
events for the "edit this" links and dynamically makes the content for 
that section editable using the contentEditable DOM interface.  Scripts 
would also be used to handle the submission.

However, without script those links should fall back to the way they 
currently work, which is to load a seperate page with the editable 
markup in a textarea for the user.  Additionally, that textarea could 
have an accept="text/html" attribute, from which (even without JS 
enabled) the user agent could choose to load an HTML editor for the user 
(whether that be for just providing syntax highlighting in code view or 
a WYSIWYG style editor).

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.

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