This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Appendix D, List of URI Attributes gives the 'icon' attribute of the 'COMMAND' element as one of the attributes that should be escaped. However, neither HTML 4 nor HTML 5 appear to define an element named 'command'. https://www.w3.org/TR/html4/index/elements.html https://www.w3.org/TR/html5/index.html#elements-1 There is also a test, Serialization-html-2, which tests that HTML 5.0 elements with empty content model are serialized using only a start tag. This test expects an element named command to be serialized as HTML.
It's difficult to keep pace with a "living standard": https://www.w3.org/wiki/HTML/Elements/command https://developer.mozilla.org/en-US/docs/Web/HTML/Element/command
'command' was in a working draft of html5 but removed in 2012, well before it went REC in 2014: https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html I agree with Alejandro - it is incorrect for serialization to normatively reference this element as it does currently. Likewise, the expected result of Serialization-html-2 is incorrect.
In the spirit of due diligence, I looked to see if COMMAND were present in any earlier versions of HTML; I didn't find it. It looks as though two things should be done: (1) we need to write an erratum to remove the mention of command/@icon, and (2) to fix the expected result of the test. The WG discussed this bug on our call of 13 June 2017 and agreed to take the two actions just mentioned.
This also affects the following xslt30 test cases: output-0216 output-0217 output-0222 output-0223 I shall fix these without a further bug report. Note: I have changed these tests to remove use of the "command" element. The revised tests will pass whether or not a processor has implemented this erratum.
I have likewise fixed the QT3 test Serialization-html-2, which appears to be the only QT3 test affected by the erratum.
> Note: I have changed these tests to remove use of the "command" element. The revised > tests will pass whether or not a processor has implemented this erratum. I disagree. The correct fix for Serialization-html-2 is to update the expected result rather than changing the test query to avoid the issue. Also, the proposed erratum and the issue with this test are both concerning the command element but they are not directly related. Implementations should be passing this test regardless of the erratum.
Perhaps we need some process on this. I'm reluctant to cause implementations to fail a test when they implement the spec as published; I would think that a test that relies on an erratum being implemented should be explicitly flagged as such, and the dependency should be isolated to a very focussed test for that erratum. Implementors will have different policies for implementing errata; some may want to wait for the next major release of a product, or for the errata to be integrated into a new spec edition.
I don't see this as a significant interoperability issue. A smart implementation would probably have a configurable list of elements to be serialized as empty, and attributes to be quoted, I suppose. For the now, since command isn't in HTML, it should be fine to serialize it in HTML style when it's empty and you're generating HTML 5, and quoting the attribute isn't going to hurt either. Not doing those things also isn't a problem, since the element isn't implemented in HTML agents. So it doesn't seem worth expecting implementations to change, and deleting the tests doesn't sound like a bad idea to me. It probably should not be an error to have a non-empty element called command, although it would also (arguably) be unwise as there may well be HTML agents that *do* recognize it as a "null" (EMPTY) element and including it in HTML files could therefore lead to really obscure interoperability problems.
Fixed in errata document. See https://www.w3.org/XML/2017/qt-errata/xslt-xquery-serialization-31-errata.html#E1 Many thanks.