[whatwg] Re: Simple template-based editing

Matthew Raymond mattraymond at earthlink.net
Fri Sep 30 00:45:44 PDT 2005

Lachlan Hunt wrote:
> Andrew Fedoniouk wrote:
>>Instead of having contentEditable attribute in our rendering engine we've 
>>introduced new input element <htmlarea> analogous to <textarea>.
> We had a similar discussion recently on the WHATWG list [1] about 
> contentEditable vs. htmlarea vs. textarea.  The general feeling, AIUI, 
> was that <textarea accept="text/html"> and a hypothetical <htmlarea> 
> element would be semantically equivalent,

   Initially I believed that, but after some discussion, I realized that
 <textarea accept="text/html"> has some very serious DOM and CSS issues.

> and that contentEditable is
> also needed for different use cases, mostly because, unlike textarea, 
> (1) its content can be styled with CSS and (2) its content can be 
> accessed/manipulated through the DOM interface.

   And <htmlarea> element will fit those cases as well. The
|contenteditable| attribute is better suited for situations where
editability is dynamic, however. For a simple rich editing control,
though, <htmlarea> is superior.

> For textarea, it's up to the UA to provide the editing environment, 
> whether it be a WYSIWYG type of editor, a textarea with syntax 
> hilighting, or whatever else.  Plus the textarea at least falls back to 
> a textarea for UAs that don't provide such editing abilities and is more 
> flexible in that it can accept any type of text input, such as text/*, 
> */*+xml, etc, whereas htmlarea is limited to HTML only.

   Yeah, <textarea> has the corner on backwards compatibility. Sometimes
I wish HTML had a sort of try/catch functionality:

| <try id="rich1">
|   <htmlarea>[...content...]</htmlarea>
| </try>
| <catch for="rich1">
|   <textarea accept="text/html">[...content...]</textarea>
| </catch>

   I don't like it, but you can see where I'm going with this...

More information about the whatwg mailing list