W3C home > Mailing lists > Public > public-multilingualweb-lt-comments@w3.org > July 2013

Re: Comments on section 6.2 of ITS 2.0

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Fri, 05 Jul 2013 13:07:44 +0200
Message-ID: <51D6A900.30304@disruptive-innovations.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:28 UTC