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

Re: Comments on section 6.2 of ITS 2.0

From: Jirka Kosek <jirka@kosek.cz>
Date: Fri, 05 Jul 2013 13:36:30 +0200
Message-ID: <51D6AFBE.8020304@kosek.cz>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: public-multilingualweb-lt-comments@w3.org
On 5.7.2013 13:07, Daniel Glazman wrote:

> 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.

OK, but for editor you don't have to touch document then at all. My
expectation would be that if you need to process ITS inside editor you
must build some sort of separate datastructure holding all global rules.
So you can run extra parsing on <script> elements only for sake of
getting all global rules.

> Jirka, I think I can safely be called an expert of wysiwyg editors

No disagreement on this :-)

> 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.

I wasn't saying anything about total cost of such change in an existing
product. But there are already several implementations of this so it's
certainly doable, although it might be expensive.

> 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.

Global rules are always evaluated against one document, so I don't think
any problem with changing context. The only trouble here is to properly
extract all global rules.

> 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.

It's a pity you haven't chimed into discussion earlier. I don't think
that we can retain inline global rules if you insist on producing same
DOM for both HTML and XHTML.


  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
    Bringing you XML Prague conference    http://xmlprague.cz

Received on Friday, 5 July 2013 11:36:54 UTC

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