- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 02 Nov 2007 18:40:06 -0800
- To: Martin Atkins <mart@degeneration.co.uk>
- CC: public-html <public-html@w3.org>
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