[whatwg] What exactly is contentEditable for?

[Lachlan Hunt]

Olav Junker Kjær wrote:
> Lachlan Hunt wrote:
>> How is that 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?
> 
> The point of contentEditable is that some areas of a page can be made 
> editable (and editing toggled on and off), while still maintaining the 
> styling and structure of the document. This is really useful for CMS'es 
> and other kind of editors - template editing and so on.

I'm not disputing the fact that there is an unfortunate demand for 
embedded WYSIWYG editing in web based CMSs, it is the conceputally 
broken implementation I'm against.

> contentEditable is quite clean since you just toggle an attribute.

No, it's messy because it mixes normal document content with user input 
in a way that does not, by design, degrade very gracefully at all 
without scripting.

> With your proposal, the editable element should toggle between the original 
> content, and a textarea element containing content,

Which, from a user's point of view, is how contentEditable is generally 
implemented by authors within web pages.  Take, for example, the example 
provided on MSDN [1].  That provides both a content editable region and 
a textarea.  Although they are clearly seperated from each other, the 
concept of switching between the two editing modes is still there.

Now, take a look at Cameron Adams' "widgEditor" [2]: an implementation 
using script to dynamically replacce an ordinary textarea with a content 
editable region with the ability for the user to switch between the two.

> now HTML escaped, but still rendered as if it were ordinary content,

It had to be escaped because the <textarea> contains #PCDATA despite the 
fact that implementations tend to treat it more like CDATA, with the 
exception that they still process entity and character references.

>> User can edit with plain text editor or UA can load WYSIWYG editor for 
>> text/html (or whatever ever MIME type is specified)
> 
> But this considers the editable content as just an arbitrary content 
> type which should be edited in some external editor.

It doesn't necessarily have to be an external editor, that aspect is 
implementation specific.  A UA could quite easily replace the text area 
with a content editable region, much like the widgEditor script does. 
Another UA could alternatively load an editor plug-in like XStandard 
into the page; and another could even, theoretically, launch an 
application like dreamweaver.  The point is that the markup should not 
be concerned with the actual implementation details, like 
contentEditable is.

> The point of contentEditable is that the editable content is HTML

The point of the suggested <textarea content-type="text/html"> was that 
the editable content is HTML; what's the semantic difference?

> and an integrated part of the containing page, which enables much cleaner
> "in place" editing.

Perhaps, cleaner from a user's point of view, but, IMHO, certainly not 
cleaner from an author's and markup point of view.  However, as I've 
said above, there's nothing stopping a UA implementing the interface for 
my suggestion like the content editable interface.

> If you just consider the editable content an arbitrary  blob of editable
> content, you wouldn't e.g. expect styles from the containing document
> to inherit into the editable HTML, which is a major point of contentEditable.

That is conceptually a preview mode and there's nothing stopping the UA 
providing such a view with either method.  In fact, there are several 
examples of authors providing script based previewing.  See Jon Hicks' 
weblog comment system [3] for one.  That particular example uses Textile 
for editing, rather than HTML, but the concept is still the same and 
with script enabled, the user should see a preview of the content below, 
as they type.

> Also consider that editable areas may contain non-editable islands which 
> aganin may contain editable areas. How would that be expresses using 
> TEXTAREA ?

That's a usability nightmare, it wouldn't make much sense for part of 
the content to be editable and other parts not.  If you have seperate 
sections to edit, provide seperate form fields for each one.

> I dont see how its "conceptually broken".

Well, firstly, because the whole idea of editing a semantic langauge 
like HTML with a very presentationally oriented WYSIWYG system is 
broken.  That applies to all WYSIWYG HTML editors (not just 
contentEditable) which are not helped by the presence of presentational 
toolbar functions (eg. the typical bold, italic, font colour, alignment 
buttons, etc. found in a typical editor's toolbar).  However, even 
ignoring the problems of WYSIWYG editing for HTML, contentEditable is 
still conceptually broken.

The attribute is behavioural, not semantic, and has no place within a 
semantic language.  Although, there may be some arguments for 
retaining/standardising the scripting interface for it based on this 
point alone, I don't support that option either.

A content editable region is conceptually a form control implemented as 
regular content with a behavioural attribute.  It requires a script to 
write the content into a form control for submission and it does not 
degrade gracefully at all.

Although, the widgEditor example I mentioned earlier does degrade to a 
regular text area (because the script dynamically replaces the textarea 
with the contentEditable region), that just further emphasises the fact 
that it is conceptually nothing more than a form control (specifically a 
textarea) and should be implemented as such from a markup perspective.

>  Its very useful, despite its shortcomings.

The functionality provided from a user's point of view may be very 
useful for some (though I personally think HTML should not be edited 
with WYSIWYG editors, especially with such poorly implemented editors), 
the implementation using contentEditable is a complete disaster.

If a user wants a WYSIWYG editor to write HTML, leave that up to the UA 
to implement, not the author.  The author should only need to specify 
what kind of input is expected, *not how it should be input*.

There is a precedent for this kind of implementation.  Consider some of 
the Firefox extensions that allow users to insert BBCode or HTML markup 
into textareas via a context menu.  There's nothing to stop such 
extensions replacing the text area with a content editable region, at 
the user's request, for the same purpose.

In fact, if there were an attribute that specified the content to be 
text/html, there would be nothing to stop the UA automatically replacing 
the textarea for the user.

[1] 
http://msdn.microsoft.com/workshop/samples/author/dhtml/refs/editRegions.htm
[2] http://www.themaninblue.com/experiment/widgEditor/
[3] 
http://www.hicksdesign.co.uk/journal/now-powered-by-textpattern-4#commentform

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