Re: @contenteditable versus <richtext>

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.

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.

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)

-- 
Jon Barnett

Received on Saturday, 3 November 2007 14:46:45 UTC