[whatwg] What exactly is contentEditable for?
mattraymond at earthlink.net
Mon Aug 29 10:53:04 PDT 2005
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
>>>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
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
> 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
> 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.
More information about the whatwg