[whatwg] What exactly is contentEditable for?

[Matthew Raymond]

James Graham wrote:
> Matthew Raymond wrote:
> 
>>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.
> 
> 
> Right but there's nothing to stop a UA creating a DOM from the text in 
> the textarea and making this avaliable in some implementation-dependent 
> way.

   Yes there is: XHTML. Legacy XHTML user agents will treat the document
as invalid. In theory, you could require that the initial text be
encoded and transformed into HTML at load time, but that's a pain for
developers, and some have already voiced their opposition to it.

> I can certianly imagine a Firefox extension designed to replace a 
> <textarea accept="text/html"> with an <iframe contentEditable> to allow 
> WYSIWYG HTML editing.

   I don't like the idea of a rich control as being the OPTIONAL method
of editing the content. In the long term, people will just use
|contenteditable| and XBL2, which is suboptimal from a compatibility and
efficiency standpoint.

> I can equally imagine a situationwhere WYSIWYG 
> isn't required and instead the textarea is presented as an ordinary 
> control but with UA-provided syntax highlighting (this should be easy to 
> implementgt where browsers use native widgets that already support 
> highlighting) or a situation where the user is given an "edit..." button 
> on the textarea that opens the contents in an emacs (or other external 
> editor) buffer and allows changes to be made.

   That would be nice in some cases, but it doesn't really match the
rich textbox use case. Besides, I don't advocate the removal of
|accept|. It's great for stuff like BBCode and the like.

> Clearly these last two
> willalso work if the accept value is application/javascript or 
> whatever,as well as HTML.

   Exactly. <textarea accept> is better suited for enhanced editing,
whereas <htmlarea> is better suited for WYSIWYG-style editing.

> Not having a required WYSIWYG rendering for <textarea 
> accept="text/html"> may be a strength rather than a weakness.

   That depends on the use case. It's a strength for experts that want
control of the actual markup. For more basic users, they may not even
understand the markup and would prefer a simple WYSIWYG editing interface.