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
