Created attachment 51474 [details] testcase 1 Browsers tested: Safari 4.0.5(531.22.7): Fail Chrome 5.0.342.3: Fail Firefox 3.6: OK IE 7: OK IE 8: OK (In IE 8, it runs in IE7 Standards mode by page default) What steps will reproduce the problem? 1. Launch the url in each browser 2. Pay attention to the top area of the page What is the expected result? Chrome and Safari should better show the same UI as that in IE and Firefox. What happens instead? In Chrome and Safari, the page loses the '新浪论坛' icon at the top-left side and shows the top login area is in a different color from that in IE and Firefox. Please provide any additional information below. Attach a screenshot if possible. Thy this page: http://bbs.club.sina.com.cn/group.php?gid=26&tree=1 In its css file(http://sjs.sinajs.cn/tiezi/css/bbs2/dev.css?38.css), there are more than one "charset" lines. All style definition right following the charset lines will be missed expect the first charset line. Yes, this issue is caused by mis-using of "charset", but why could not we handle it correctly while IE and Firefox both can? Attached please kindly find my recuded test-case. In my first test-case, the 2nd and 3rd selectors are both ignored in Safari and Chrome. But they are having effect in Firefox and IE. And in the second test-case, you will see that the first selector which just follows the '@charset' right in the first line take effect while the second selector doesn't. Thanks!
Created attachment 51475 [details] testcase 2
It's reported in Chromiub bug tracker (http://crbug.com/38877 )
See also: bug 18265. Seems that Firefox behavior is not what we thought it was.
I'm not 100% clear on the expected behavior here. Should we be ignoring these @charset directives or should we be switching charsets as we go?
The spec just says that such stylesheets are invalid, so all we can do is check other browsers' behavior. My guess is that no browser switches the encoding. They may ignore misplaced charset declarations, or they may honor the first, or the last. The first option (ignoring) seems best and most likely to me in the absence of hard facts.
(In reply to comment #5) > The spec just says that such stylesheets are invalid, so all we can do is check other browsers' behavior. > > My guess is that no browser switches the encoding. They may ignore misplaced charset declarations, or they may honor the first, or the last. The first option (ignoring) seems best and most likely to me in the absence of hard facts. in http://www.w3.org/TR/CSS21/syndata.html#charset it says "User agents must ignore any @charset rule not at the beginning of the style sheet."
*** Bug 44857 has been marked as a duplicate of this bug. ***
See also: bug 21628.
Created attachment 65952 [details] proposed fix
Comment on attachment 65952 [details] proposed fix Rejecting patch 65952 from commit-queue. Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--wait-for-httpd', '--ignore-tests', 'compositing,media', '--quiet']" exit_code: 1 Running build-dumprendertree Compiling Java tests make: Nothing to be done for `default'. Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests Testing 20871 test cases. fast/loader/recursive-before-unload-crash.html -> failed Exiting early after 1 failures. 14296 tests run. 254.34s total testing time 14295 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 1 test case (<1%) had stderr output Full output: http://queues.webkit.org/results/3881178
Comment on attachment 65952 [details] proposed fix Sorry, that's a top flaky test.
Comment on attachment 65952 [details] proposed fix Rejecting patch 65952 from commit-queue. Failed to run "[u'git', u'svn', u'dcommit']" exit_code: 1 Last 500 characters of output: ced-charset.html M WebCore/ChangeLog M WebCore/css/CSSGrammar.y A repository hook failed: MERGE request failed on '/repository/webkit/trunk': Commit blocked by pre-commit hook (exit code 1) with output: The following files contain tab characters: trunk/LayoutTests/fast/css/misplaced-charset.html Please use spaces instead to indent. If you must commit a file with tabs, use svn propset to set the "allow-tabs" property. at /usr/local/git/libexec/git-core/git-svn line 572 Full output: http://queues.webkit.org/results/3856188
Committed <http://trac.webkit.org/changeset/66486>.