[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

Hallvord Reiar Michaelsen Steen wrote:
>>Whilst I agree the concept of contentEditable is not good, I don't
>>think it should be solved by trying to modify the existing behaviour
>>the accept="text/html" is a much better way of meeting your use case.
> 
> If it gets implemented in a WYSIWYG form...
> We have already discussed back and forth on whether using a TEXTAREA 
> is better, and I think we all agree that neither approach is really 
> good. Saying that contentEditable elements can become part of a form 
> will give us the best parts from each of the worlds IMO.

   I don't. You're talking about making every HTML element a potential
form control. This is just plain confusing for the developer, not to
mention hard to implement and technically complex. If I have a form
element with |contenteditable|, can it have a |form| attribute? Can
elements with both |contenteditable| and |form| also have |readonly| and
 |disabled| attributes? I think you're opening a real can of worms here.

   Personally, I like the following idea better:

1) Keep |contenteditable| (with some additional definition of behavior),
and position it for use in situations where you'll be dynamically
editing the entire document. Might be ideal for certain AJAX applications.

2) Keep <textarea accept="text/html"> as-is, and suggest that it be used
in backwards compatibility situations and for when you might want an
enhanced editing control for hand-coded HTML.

3) Create a new <htmlarea> element (which I have defined elsewhere),
that embodies the closest thing to an ideal HTML-based form control.
Best for situations where you have a fixed parent element that you want
to submit in most situations.