18395 2012-07-25 12:28:52 +0000 Encoding Sniffing Algorithm: Overrides apply to nested browsing contexts 2012-10-02 21:13:37 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC All RESOLVED NEEDSINFO http://dev.w3.org/html5/spec/Overview#encoding-sniffing-algorithm P2 normal --- 1 xn--mlform-iua ian ian mike public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 71442 0 xn--mlform-iua 2012-07-25 12:28:52 +0000 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 75101 1 ian 2012-10-02 19:43:07 +0000 This seems to be already in the spec, as step 6 ("Otherwise, if the Document is in a nested browsing context, return the encoding of the browsing context container's Document's character encoding, with the confidence tentative, and abort these steps"). Are you saying it should be moved up? If so, do you have a test that demonstrates that specifically? 75113 2 xn--mlform-iua 2012-10-02 21:13:37 +0000 (In reply to comment #1) Right! Formally this bug is now solved. HOWEVER, some refinement is due: Like Henri [1] and I [2] have said, some refinements are needed: The encoding of the parent context should not apply when parent and child are of different origins and, also, not if the parent is of an ASCII-incompatible encoding (such as UTF-16). See my at test cases. [3] [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18474#c3 [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037226.html [3] http://www.målform.no/blog/utf8files/locale_default_vs_doc_of_parent_browsing_context/