[whatwg] What exactly is contentEditable for?

[Ian Hickson]

On Wed, 24 Aug 2005, Lachlan Hunt wrote:
> > 
> > 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.

Indeed. contentEditable is a core platform feature, as someone pointed 
out, rather than a final widget.

Similarly, ondragstart and co are platform components, not final widgets. 
You can't do anything with ondragstart on its own, especially without 
scripting. But it is still important.


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

Having the content attribute is important for describing the initial state 
and for being able ot serialise the current state on the fly.


> 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! :-)


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


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

Yup.


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

Yup.


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

Yup.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'