W3C home > Mailing lists > Public > public-html@w3.org > November 2007

Re: @contenteditable versus <richtext>

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sat, 03 Nov 2007 11:38:09 -0800
Message-ID: <472CCE21.7000205@terrainformatica.com>
To: Jon Barnett <jonbarnett@gmail.com>
CC: Martin Atkins <mart@degeneration.co.uk>, public-html <public-html@w3.org>

Jon Barnett wrote:
 > On 11/2/07, Andrew Fedoniouk <news@terrainformatica.com> wrote:
 >>>> Such <richtext> shall use so called "flat DOM" so
 >>>> there cannot be:
 >>>>  1) nested <div>s;
 >>>>  2) <li> is a kind of <p> - can contain only text and spans.
 >>>>  3) nested tables;
 >>>>  4) only two levels of spans are allowed - so called
 >>>>     background and foreground spans;
 >>>>  5) there are no <font> and <span> elements inside the editor.
 >>>>
 >>> What is the behavior if the source document supplies some HTML that
 >>> does not fit the above constraints?
 >>>
 >>>> <richtext tools=#tools>
 >>>>   <p>Hello World</p>
 >>>> </richtext>
 >>> This has the potential to break if the source HTML contains errors,
 >>> since it may throw off the parser and cause the document to be edited
 >>> to "escape" out into the page.
 >
 > Instead of this, I would prefer <textarea mode=richtext>&lt;p&gt;Hello
 > world</textarea> or something like that, where the contents of the
 > textarea are text representing HTML.

To do massive escapement of html markup is a bad idea in general.
As an option we may use different brackets for inner markup:

<richtext tools=#tools>
   [p]Hello World[/p]
</richtext>

But I think that declaring <richtext> element as [P]CDATA-only-inside 
element would be just fine.

If UA that does not support richtext will get this:

<richtext tools=#tools>
   <p>Hello World</p>
</richtext>

then it will be rendered as non editable <p>Hello World</p>.


 >
 > This is what I (and other RTEs) do, and then use JavaScript to replace
 > that textarea with an IFRAME containing the document with "designMode"
 > enabled.  It's a complex chunk of Javascript.
 >
 > TEXTAREA would degrade gracefully to a regular textarea.  This is what
 > websites do that allow HTML tags in their comments and forum posts.

<textarea> is declared currently as

<!ELEMENT TEXTAREA - - (#PCDATA)

So this:

<textarea>
   <p>Hello World</p>
</textarea>

works in all modern UA without any escapement.
Thus it is possible to reuse <textarea> with additional attributes as
a <richtext>:

<textarea type="wysiwyg" content-type="text/html">
   <p>Hello World</p>
</textarea>

or so. And this will be backward compatible.

Having them both (<textarea> and <richtext>) will allow
you to choose proper fallback schema - what author will want to be 
presented in case when UA is not supporting WYSIWYG editing.

 >
 > The only difference between the plain textarea and the one replaced
 > with RTE is the way line breaks are handled.  When the form is
 > submitted, a flag needs to be passed to let the server know if line
 > breaks shoiuld be preserved (by converting them to <br> tags or
 > heuristically placing <p> tags)
 >

I do not understand why do you need this. richtext aware application 
will get the value as a markup - pretty much in the same way as if you 
will submit html file by <input type="file">.

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Saturday, 3 November 2007 18:37:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:09 GMT