Re: @contenteditable versus <richtext>

Martin Atkins wrote:
>
> Andrew Fedoniouk wrote:
>>
>> flat DOM --------------------------
>>
>> 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.

Content of <richtext> cannot contain another <richtext> inside so
content parsing stops on first <richtext> or </richtext>.
I cannot see any problems here.  In general error handling rules are
close to parsing of such elements as <script>, <style> or <xml>.
In practice <richtext> accepts some subset of html or wiki markup so
parser of host page is passing everything in between <richtext> and
</richtext> "as is" to the parser of <richtext> component.

>
> Not being able to tolerate invalid data would make this element 
> largely useless for any application which also allows raw entry of 
> HTML source from users as an option, since any mistake from the user 
> in raw entry mode could break the WYSIWYG editor.

I do not see any major problems here.
For  <div conteneditable> cases, yes, this is a problem. But <richtext>
is in principle more robust in such situations.

Andrew Fedoniouk.
http://terrainformatica.com



-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 3 November 2007 01:39:33 UTC