This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #18395 +++ Proposal: Extend the encoding sniffing algorithm with a new step after the current first step (about user overriding), like so: #. If the current document lives in the 'nested browsing context'[1] of a document in a 'parent browsing context' whose encoding has been overridden at the request of the user, then return the encoding of the parent browsing context, and abort these steps. [My note: Doesn't apply if the current doc is XML, [see bug #1], or if it contains the BOM, confer Bug 17810/Bug 15359.] Justification: Currently, when a user agent obeys a user's request to override the encoding of a parent browsing context, then [NB: I did not test the relevant version of IE yet: IE8/IE9/IE10], unless the document of the child browsing context contains a BOM or [see bug #1] the document is an XML document, then they all apply the encoding of the parent browsing context to the child browsing context as well. More data in my related blog post.[2] [1] http://dev.w3.org/html5/spec/Overview#nested-browsing-context [2] http://målform.no/blog/white-spots-in-html5-s-encoding-sniffing-algorithm
(no need to mention XML docs, since they don't go through this algorithm anyway)
Chrome ignores it if there's a BOM, but Opera and Firefox don't. IE doesn't seem to override the child iframe at all. So the spec seems right as-is: it's a UI issue in step 1. http://www.hixie.ch/tests/adhoc/html/parsing/encoding/iframes/
(In reply to comment #2) > http://www.hixie.ch/tests/adhoc/html/parsing/encoding/iframes/ Your test resultss are bogus. Test '001.html' is probably buggy: I am perplexed by this Turkish encoded test. When I replicate that test, then I can easily override the encoding in IE: <http://malform.no/blog/utf8files/001.html> I have no idea why your site gives a different result, but perhaps you need to check whether there is an error with your copy of that test or with the server. Test '002.html' is irrelavant due to the BOM: Internet Explorer, Webkit and Chrome already do ignore user overrides when there is a BOM. And Firefox has decided to ignore the user overrides, as well <https://bugzilla.mozilla.org/show_bug.cgi?id=716579#c14>. Thus, the BOM should be evaluated *before* the ifram override rule steps in (yes, from the angle of the child browsing context, when *it* is 'the current document', then the BOM, should win and not the override in the parent context). [And that is *another* bug with the current algorithm - for some reason you have made user overriding the first step, when it should have been the second step, after BOM.] If one *does* remove the BOM in an UTF-8 document, then I have no problems making IE10 Release Preview (in all browser moes) override the encoding of the child iframe: http://malform.no/blog/utf8files/iframe_doc_vs_your_encoding_override_of_the_parent_doc
I like how you assume there's a bug in my test, rather than assuming it's a bug in yours or a bug in IE. In any case, the point is that this is all a UI issue. The spec can't say what the UI is to act like.