14676 2011-11-02 10:03:30 +0000 For UTF-16, the oder of the steps in "change the encoding" doesn't seem right. 2012-07-18 18:46:48 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#changing-the-encoding-while-parsing P3 normal Unsorted 1 contributor ian ian kennyluck mike contributor oldest_to_newest 59473 0 contributor 2011-11-02 10:03:30 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html Multipage: http://www.whatwg.org/C#changing-the-encoding-while-parsing Complete: http://www.whatwg.org/c#changing-the-encoding-while-parsing Comment: For UTF-16, the oder of the steps in "change the encoding" doesn't seem right. Posted from: 114.43.127.97 by kennyluck@csail.mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 59476 1 kennyluck 2011-11-02 10:19:22 +0000 s/oder/order/ Consider a simple test case like, <script>alert(document.characterSet||document.charset)</script><meta http-equiv="content-type" content="charset=utf-16"> . By the pre-scanning algorithm, the first try should be utf-8. But then in step 1 of the "change the encoding" uft-16 isn't at that moment equivalent to utf-8, so a reload is possible depending on how you interpret the "may" in step 4. Gecko doesn't reload in this case. IE first gives the default encoding (which contradicts the pre-scanning algorithm but that's another issue), and then "unicode" (but decodes the content in "utf-8"). Anyway, is allowing reloading in my example intentional? If not, I propose we move step 3 before step 1. 59521 2 contributor 2011-11-02 20:40:37 +0000 Checked in as WHATWG revision r6814. Check-in comment: When a page interpreted as UTF-8 has a <meta charset> saying UTF-16, the spec used to say to reload even though the encoding didn't change. http://html5.org/tools/web-apps-tracker?from=6813&to=6814