- 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