- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Fri, 05 Jul 2013 13:07:44 +0200
- To: Jirka Kosek <jirka@kosek.cz>
- CC: public-multilingualweb-lt-comments@w3.org
On 05/07/13 12:47, Jirka Kosek wrote: > It's certainly little more difficult to handle both XHTML and HTML, but > not that much. If you use HTML parser you can simply add additional > processing step which will run additional parsing step on text node in > all <script type=application/its+xml> elements and replace text node > with a parsed tree. No. There is nothing I can replace because my users will not tolerate it. The app just cannot modify the document tree like that in an editor. > IMHO options 1 and 2 can be implemented in ~10 lines of code. Jirka, I think I can safely be called an expert of wysiwyg editors and I am telling you that even if it is implementable in 10 lines of code, you are making assumptions about what can be done by the editing tool (like above) and the performance/maintenance of such a code that are wrong. If editors have to check the flavor of HTML they deal with at every single step of ITS manipulation, that's a cost. If we have to deal on one hand with a DOMDocument parsed from the script's contents and on the other a DOMElement being the <its:rules> elements, that has a cost and I don't even mention the fact |document.evaluate()| will process XPath queries in two different contexts. For me as a editor vendor, such an issue is important enough to raise an objection to the PR release. html5 and xhtml5 should result in the same DOM tree and that's not the case here. </Daniel>
Received on Friday, 5 July 2013 11:08:07 UTC