[whatwg] What exactly is contentEditable for?

Note: The quoted text has been rearranged for clarity.

Ian Hickson wrote:
> The answers to your questions are [...]
>
> On Wed, 24 Aug 2005, Matthew Raymond wrote:
>> For example, are the HTML contents loaded into the DOM?
>
> [...]only as text nodes[...]
>
>> Are they treated like a separate document in an <iframe>,
>> or are they more like the contents of <div contenteditable>?
>
> [...]no [and] no[...]

>> Do they inherit their styles from the current web page?
> 
> [...] no. It's just a <textarea> that 
> can have syntax highlighting or other features, with all that being left 
> up to the UA to decide, just like with text/plain <textarea>s.

>> This means the child text of <textarea> must be maintained 
>> or you can't do a reset for that control.
> 
> Yes.
>
>>So, where are the modified
>>HTML contents of the control when it's being edited? In the DOM?
> 
> In .value (as opposed to .defaultValue).
> 
> This is _exactly_ the same as for a text/plain <textarea>.
>
>>This would suggest that <textarea> HTML contents need to be in a 
>>separate document object. If that's the case, how is styling handled? 
>>Does it inherit from the parent document? What would a selector like 
>>"textarea > p" do?
> 
> You seem to be making unwarranted assumptions about this feature. There is 
> _absolutely no difference_, from an authoring or DOM perspective, between 
> a text/plain <textarea> and a text/html <textarea>. The difference is 
> _only_ from a UA and user point of view, and only in terms of UI.

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.

2) There is no way to use the DOM to manipulate the contents of the
<textarea> without using a proprietary UA interface.

>>>Well, we already have <textarea accept>. It's up to you guys to
>>>convince UA makers to implement it. :-)

   With these limitations, no one is going to try to convince UA vendors
to implement this. The |accept| attribute seem to be no better than
using microformats. You might as well remove the attribute form the WF2
spec.

   The simple fact of the matter is that, with the version of HTML5 you
currently propose, there is no way to submit HTML in the DOM without
scripting.

Received on Friday, 26 August 2005 00:35:57 UTC