[whatwg] What exactly is contentEditable for?

Olav Junker Kjær olav at olav.dk
Mon Aug 15 14:00:45 PDT 2005


I'll describe a use case first, since I think it answers some of your
questions.

Consider a CMS with a browser-based editing interface. For ease of use,
it is designed so that pages in "edit mode" looks as much like the
public site as possible. Different people are allowed to edit different
parts of the site. E.g. the marketing department are only allowed to
edit the "content area", while the CEO is allowed to edit the header and
footer which is shared on every page, but not allowed to change the
content area.
The CMS toolbar has a lot of custom editing commands like "insert
company logo here", "format text as unreadable legalese" and so on,
which can be used on the editable content.


The "killer feature" of contentEditable is that it is orthogonal to 
document structure. You can make any element - inline or block, anywhere 
in the document - editable, without changing the basic structure of the 
document. If an extra element (like <htmlarea>) were required around the 
editable content, it would get quite tricky, since this element would 
have to be transparent wrt. style and DOM, and it should be able to work 
both in  block and inline context.

>    What are you talking about? Why wouldn't a UA use the styling of the
> parent document to style the HTML inside a <textarea usehtml> element?

They cant, since a textarea contains only character data, not markup. It
would seem a giant hack to me, if browsers would take the plaintext
content of textarea, un-encode it and parse it as HTML, and then render
it and generate a DOM-subtree below the textarea.

>    Here's how it's conceptually broken: How do you submit the edited
> content without scripting? 

You dont. You use scripting. XMLHTTP requires scripting too, its still a
useful feature.

> How do you edit the content in a legacy
> browser? 

You dont. In a legacy browser, the content is rendered as ordinary 
content, but not editable. In most cases this is much better fallback 
that showing some incomprehensible code in a textarea. Most people dont 
know HTML code.

> How do you style the read-only or read-write contents with out
> using those G*d-awful versions of the :read-only and :read-write
> pseudo-classes from CSS3-UI? 

Isnt this really an objection against CSS3-UI, rather than contentEditable?

> Why are we allowing editing outside a form
> or controls context?

As in the use case, different parts of the document may be editable at 
different times. In some cases you might even want to edit the form to 
insert new controls.

Form controls are useful for a "fixed" editable area. E.g. if a blog had 
a comment box which allowed wysiwyg HTML entry, it would make sense to 
have e.g. a <htmlarea> form element for this. <htmlarea> could work like 
a <div contenteditable> but in addition work as a form control (support 
validation, participate in submission and so on).

In this context I would prefer a new tag <htmlarea> rater than <textarea 
usehtml> since the new tag could be defined to allow mixed content 
rather than just plaintext as <textarea>. In any case, this is a 
different use case than the case for contentEditable.

Regards
Olav Junker Kjær



More information about the whatwg mailing list