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 12:17:23 +0200
Message-ID: <51D69D33.5050507@disruptive-innovations.com>
To: Jirka Kosek <jirka@kosek.cz>
CC: public-multilingualweb-lt-comments@w3.org
On 05/07/13 11:34, Jirka Kosek wrote:

> There is easy fix -- do not use this feature which what the spec
> encourages, see note at the end of section 6.2:
> "Note:
> It is preferred to use external global rules linked using the link
> element than to have global rules embedded in the document."

No, it is not an easy fix. You see it as an easy fix because you
look at users (hear document authors) only; I am an editor tool

It is a Note and it's not mandatory to obey. I am then saying the spec
should deal with the fact it is explicitely allowed AND implementations
MUST deal with that case. As an editing environment author, I cannot
skip inline global rules, sorry; a spec is a spec. Possible options:

1. do nothing, burden is on implementations. But an element that can
    be parsed in two different ways in the html serialization of html5
    and the xml serialization of html5 is in my opinion a quite serious
    design flaw... The resulting DOM tree should be the same for both
    html5 and xhtml5.

2. clarify what happens when a <script type=application/its+xml> is
    used, depending on html flavor and browsers' behaviour

    2.a. a note explaining the issue ?
    2.b. or restrict inline global rules to (for instance)
         non-xml HTML?

    and burden remains on implementations

3. normatively force the contents of a <script type=application/its+xml>
    element to be encapsulated inside a CDATA section or XML comment
    inside XHTML documents. At least the resulting DOM in both html5 and
    xhtml5 is made of a CharacterData node. That is an acceptable

4. remove inline global rules from spec

My preference clearly goes to option 3. Options 1 and 2 are too
expensive for implementors, option 4 would be a pity.

Received on Friday, 5 July 2013 10:17:47 UTC

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