[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