- From: <bugzilla@jessica.w3.org>
- Date: Mon, 27 May 2013 13:18:55 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21818 --- Comment #6 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> --- (In reply to comment #5) > So the proposal would be to replace that with: > > """ > <p> > The Encoding declaration state may be used in HTML documents and in XML > documents. If the Encoding declaration state is used in an XML document, the > name of the character encoding must be an ASCII case-insensitive match for > the string "UTF-8" (and the document is therefore forced to use UTF-8 as its > encoding). > </p> > <p class=note> > The Encoding declaration state has no effect in XML documents, and is only > allowed in order to facilitate migration to and from XHTML. > </p> > """ > > Is that correct? Would it address your concerns? Absolutely! This seems perfect. > Has anyone checked implementations on this? I don't mind making this change > so long as browsers *really* ignore this instruction in XHTML. A test case > would be most valuable. XML 1.0 only operates the following ways of setting the encoding: * fallback/default = UTF-8 * UTF-16 (and UTF-8) sniffing * BOM * <?xml version="*" encoding="*"?> (forbidden in polyglot) * server sent HTTP Content-Type header Thus, meta elements are not included in XML’s encoding calculation rules. Neither is the XML MIME type supposed to be decided by looking into <meta>. Now, with regard to testing, then I recommend to test with a XHTML file without file extension, loaded via file:/// URL. For example a file called "test". (And not "test.html" or "test.xhtml".) But note that not all browsers will accept to open a file without file extension. (The file extension tells the mime type.) First test you could do is to check this: <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> vs this <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> RESULT: text/html, regardless (in Chrome and Firfefox. Safari refuses to open.) And so on. Other tests are certainly possible, but I think the above proves the point. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 27 May 2013 13:19:08 UTC