- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Fri, 05 Jul 2013 12:17:23 +0200
- 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
vendor...
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
compromise.
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.
</Daniel>
Received on Friday, 5 July 2013 10:17:47 UTC