[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

   Note: In the context of this email, I'm using the theoretical
attribute |usehtml| as a trigger for converting a standard text-based
<textarea> to one that supports HTML content.

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.

   How is this any different from an HTML-enabled <textarea>? You can
toggle editing with |readonly|, and the document's CSS file would
provide styling unless you override it using |style|. The only place the
structure is not maintained is within the <textarea> itself, and you
want to edit that anyway.

> This is really useful for CMS'es 
> and other kind of editors - template editing and so on.

   Not too familiar with CMSes. Can you give a short use case. It would
be very helpful.

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

| <textarea usehtml readonly><p>...Contents...</p></textarea>

   Just toggle |readonly|...

> With 
> your proposal, the editable element should toggle between the original 
> content, and a textarea element containing content, now HTML escaped, 
> but still rendered as if it were ordinary content, including inheriting 
> styles and so on from the containing document. That does not seem very 
> clean.

   First of all, the escaping, while perhaps necessary for having your
code validate, is not necessary from a practical fallback point of view.
Most browsers treat HTML tags withing a <textarea> as if they were text.
So, we simply define <textarea> for text as containing text, <textarea
usehtml> as containing HTML, and the fallback for <textarea usehtml>,
realistically, is already handled.

   Obviously, an ordinary <textarea> can style HTML contents in a legacy
browser, but that's far better than using |contenteditable|, which has
no fallback at all. With |contenteditable| in Firefox, for instance, you
get static elements.

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

   Well, the editor doesn't really have to be external. In fact, the
whole thing can be implemented in a way similar to |contenteditable|
from a UI standpoint.

> The point of 
> contentEditable is that the editable content is HTML and an integrated 
> part of the containing page, which enables much cleaner "in place" 
> editing. 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.

   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?
It's not like it's a <frame> or an <object>, after all. It's internal to
the document.

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

   Is that even handled by |contenteditable| in its current incarnation?
For that matter, it doesn't make a lot of sense from a UI standpoint.
When was the last time you edited something and were not able to delete
a specific section because it was non-editable? People wouldn't even
understand why it wasn't editable. They'd just flood webmasters with
emails about how they couldn't delete a certain section. If you must
have static content between two editable areas, why not just have
multiple editing elements:

| <textarea usehtml>Editable content</textarea>
| <p>Static content</p>
| <textarea usehtml>Editable content</textarea>

   I'm just not seeing the use case here.

   ...Wait. That said, what about this:

| <textarea usehtml name="editme">
|   <p>Editable content</p>
|   <textarea readonly>Static content</textarea>
|   <p>Editable content</p>
| </textarea>

   Hmm.

   /me shrugs.

   I don't know. Not sure I like it.

>>That would be a far better option than using contentEditable, which is 
>>not only conceptually broken, but *all* implementations of it are so 
>>incredibly broken, that trying to standardise it is like dragging a dead 
>>horse through mud.
> 
> Certainly the IE implementation (which is the only non-beta 
> implementation i know of) has its issues, but I dont see how its 
> "conceptually broken". Its very useful, despite its shortcomings.

   Here's how it's conceptually broken: How do you submit the edited
content without scripting? How do you edit the content in a legacy
browser? 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? Why are we allowing editing outside a form
or controls context?