[whatwg] What exactly is contentEditable for?
lachlan.hunt at lachy.id.au
Tue Aug 16 06:20:31 PDT 2005
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
> 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 . 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" : 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
> 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  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.
More information about the whatwg