[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

Ian Hickson wrote:
> On Fri, 26 Aug 2005, Matthew Raymond wrote:
>>So, effectively, what you're saying about <textarea accept="text/html"> 
>>is the following:
>>
>>1) The HTML in a <textarea> is unstyled (at least unstyled by the parent 
>>document) unless styles or stylesheets are specified within the 
>><textarea> contents.
> 
> There is no defined rendering for <textarea>. The UA would be perfectly 
> within its rights to interpret the contents of such an element and style 
> it using the styles of the containing document.

   The trouble is that if you don't have a DOM, CSS really doesn't make
a lot of sense. For instance, "textarea p" is illogical because the <p>
element isn't actually a child of the <textarea> because the control can
only have a text node as its child.

>>2) There is no way to use the DOM to manipulate the contents of the 
>><textarea> without using a proprietary UA interface.
> 
> Sure, you could do something like:
> 
>    my DOM = document.createElement('div');
>    DOM.innerHTML = textarea.value;
>    // ...manipulate DOM...
>    textarea.value = DOM.innerHTML;
> 
> ...or some such.

   Sure you could, but WHY?!! It's not a functional improvement over
your previous example:

| <form onsubmit="d.value = firstChild.innerHTML" ...>
|   <div contentEditable> ... </div>
|   <input name="d" type="hidden">
|   <input type="submit" ...>
| </form>

   Granted, the <textarea> still allows you to reset the control, but
you need CSS to hide the the <div>. You also need extra parsing and
serialization steps every time you manipulate the HTML inside the
<textarea>. There's also issues of managing the current text selection
that I don't think you've addressed.

>>The simple fact of the matter is that, with the version of HTML5 you 
>>currently propose, there is no way to submit HTML in the DOM without 
>>scripting.
> 
> That is certainly true, yes. I'm not sure why this is a problem, though.

   You mean other than the fact that the author has to know Javascript
just to have a rich text control? And while we're at it, let's remember
that they need scripting for resets, read-only and disabled
functionality, maxlength and any other form control-related feature.

> The scripting is simple, and would only be an [insignificant] part of the 
> actual scripting involved in writing an editing UI using contentEditable.

   Once you get beyond the most basic level of editing support, that's
no longer the case. For instance, you may need to write script to save
the editing area at load time and to restore once someone hits a reset
button. You need special CSS to handled "disabled" and "enabled" states
because an <div> with |contenteditable| won't match :disabled or
:enabled. For a "read-only" state, you have to make the value of
.contentEditable and the presentation of the <div> match the read state
of the <input type="hidden"> element you're using to submit. And what
about |required|? I thought it was created for the very purpose of
reducing the amount of script needed.

   The bottom line is that in order to simulate an <htmlarea>-like
control you need massive amounts of Javascript and specialized CSS, and
it all turns into a static, unsubmittable block of HTML if you try to
use it with a legacy browser. Remember that you'd have to put the entire
serialized contents of the <div> into the |value| attribute of the
<input type="hidden"> element _in_the_markup_ in order to simply submit
the default contents when Javascript is turned off or unavailable.


   Generally, there are five things that would make up an ideal HTML
editing control:

1) Supports the "parent" document's CSS for the control contents.
2) Supports access via DOM.
3) Supports |readonly| and |disabled|.
4) Supports reset with the serialized initial contents as the default.
5) No scripting necessary.

   According to you, <textarea accept="text/html"> takes care of 1, 3
and 5, with 4 somewhat covered as well. That's pretty close, but it's
not enough. We can never really make DOM work for <textarea> contents
because there are too many complications. An element with
|contenteditable| doesn't really work either, because it only really
matches the first two items in the list.

   Perhaps the best idea is to keep <textarea accept="text/html"> and
|contenteditable| in with their existing limitations and introduce an
official <htmlarea> form control element. This element would have the
following properties:

1) It would allow any HTML contents you can put in an <div> or <span>.
2) You could style it as easily as a <div> or <span>.
3) Because the contents are in the DOM, CSS works as expected.
4) It would have all the <textarea> attributes (save |rows| and |cols|).
5) The DOM property .defaultValue would be a serialization of the
   initial <htmlarea> contents.
6) The DOM property .value could be a serialization of the current
   <htmlarea> contents. (Pretty much the same as innerHTML.)
7) Resetting the form restores the innerHTML of the control to
   defaultValue.

   I think you get the idea. The idea is to make it behave as much like
an HTML form control as possible while still being able to use CSS and
DOM effectively. If you need backwards compatibility, you can trade off
some of the nicer features of <htmlarea> and just use |contenteditable|
or <textarea>, depending on your needs.

   I'd like to hear from Dean Edwards about how difficult this would be
to implement <htmlarea> in an HTC. If HTML5 is to be successful in the
long term, we're going to want a clean, simple control for editing and
creating HTML content.