- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 30 Sep 2005 03:45:44 -0400
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...
Received on Friday, 30 September 2005 00:45:44 UTC