[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

Ian Hickson wrote:
> On Wed, 24 Aug 2005, Matthew Raymond wrote:
>>Yeah, I think you may have a point. It may make more sense to enable 
>>editing of DOM Ranges through scripting rather than putting it in 
>>markup.
> 
> Uh, that would be unbelievably hard to implement.

   Yeah, that was already my conclusion, as I hinted to later in the
message.

>>After all, if we're going to be dynamically inserting and removing 
>>|contenteditable| all over the place, we're already using scripting. On 
>>the other hand, if you have a static block that you're going to edit and 
>>submit, an actual control makes more sense, be it <htmlarea> or 
>><textarea accept="text/html">.
> 
> Well, we already have <textarea accept>. It's up to you guys to convince 
> UA makers to implement it. :-)

   I think there are still issues to address with regards to <textarea
accept>. For example, are the HTML contents loaded into the DOM? Are
they treated like a separate document in an <iframe>, or are they more
like the contents of <div contenteditable>? Do they inherit their styles
from the current web page? I think all of this needs to be properly
defined, or |contenteditable| will win simply by virtue of inconsistent
implementation of <textarea accept>.

> It's worth bearing in mind that Microsoft originally had <htmlarea> and 
> dropped it competely in favour of contentEditable before shipping.

   I'm on the fence as to whether we need an outright <htmlarea>
element, or if we can just style <textarea>. This seems to tie into the
current discussion about styling controls on www-style. If people can be
reasonably certain that they can style <textarea accept> like a <div> or
a <span>, we won't need <htmlarea>.

>>Hmm. IE supports the .contentEditable property, so why not just drop
>>the HTML attribute |contenteditable| and leave the DOM property?
> 
> Having content attributes is good for serialising DOM states. For example, 
> the fact that the "value" DOM attribute on controls is not the same as the 
> content attribute has caused many problems and makes it impossible to 
> store the state of a modified form in a serialised format.

   I don't really see a use case, but then at this point I'm willing to
let it slide if <textarea accept> is better defined for "text/html".

   Here's an example of how poorly <textarea accept="text/html"> is
defined. When you press a reset button, the form controls return to
their defaults. So, if you press reset on a page with <textarea
accept="text/html">, it should restore the default contents of the
<textarea>. This means the child text of <textarea> must be maintained
or you can't do a reset for that control. So, where are the modified
HTML contents of the control when it's being edited? In the DOM? They
can't be children of <textarea> because it already contains the contents
it needs for the reset.

   This would suggest that <textarea> HTML contents need to be in a
separate document object. If that's the case, how is styling handled?
Does it inherit from the parent document? What would a selector like
"textarea > p" do?

   I suppose we could just make it to where <textarea> only parses the
first child node for resets, and only if it's a text node. Every other
child would be the current contents of the control. However, I think
that content would have to be dumped if you save the page to disk. Is
that any different from what we do with the contents of <input>, though?