User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 When Apache return http header "Content-Type: text/css; charset=win-1251" css don't locking good If header is "Content-Type: text/css" with out charset all work Reproducible: Always Steps to Reproduce: 1. 2. 3.
I guess mozilla doesn't support that charset name... windows-1252 should work
WFM, Mozilla 2004-11-26-06 trunk Linux.
The chief reason that Mozilla doesn't support that character set name is that it doesn't exist: in fact there are no registered character set names beginning "win-". "windows-1251" would be the correct form. Do we reject the whole style sheet if it has an illegal charset declaration?
(In reply to comment #3) > Do we reject the whole style sheet if it has an illegal charset declaration? The answer to my own question seems to be "Yes": http://smontagu.org/testcases/stylesheetencoding.html
Summary: When Apache return http header "Content-Type: text/css; charset=win-1251" css don't locking good → Stylesheet with Content-Type header including unrecognized charset is ignored
Created attachment 167208 [details] [diff] [review] Tentative patch This feels like using a sledgehammer to crack a nut, but it works at least.
Assignee: dbaron → smontagu
Status: UNCONFIRMED → ASSIGNED
So... There are 5 different sources for a charset in this code. The last two may not be relevant because maybe we vet them already, but there are three where a charset may just be specified (HTTP header, @charset rule, charset attribute on the node). They should behave the same as far as this sort of thing goes. Further, I feel that simply ignoring a charset declaration because we don't have support for it and trying to treat it as some random other charset is wrong... We do something similar for script (see bug 230104), but I'm really not to happy with that either. What do we do for toplevel documents that are encoded in a charset we don't understand?
(In reply to comment #6) Yes, I agree that whatever we do for the charset declaration in the header should be done for the other sources of charset info as well. This patch is anyway only intended as a basis for discussion. > I feel that simply ignoring a charset declaration because we don't have > support for it and trying to treat it as some random other charset is wrong... Do you agree that what we currently do is even more wrong? Which in effect is to assume that if we find a charset declaration it must be OK, and then fail later when we try to use it to decode the stylesheet. Anyway, what I am suggesting is not that we should treat a charset that we don't have support for as "some random other charset". We should just ignore it, like an unknown CSS property, and pass on to the next possible source in the hope of finding a charset that we do support. P.S. Our current default for CSS is ISO-8859-1, but I just noticed that CSS 2.1 and the current working draft of the CSS3 Syntax module specify UTF-8 as the last resort fallback. We should probably conform to that.
> Do you agree that what we currently do is even more wrong? Actually, no.... If the author explicitly specified a charset, we should use that charset instead of second-guessing the author, imho. If we don't support that charset, we shouldn't apply the stylesheet, instead of possibly applying the wrong stylesheet (gotten by treating the data as being in some other encoding). I can see the argument for fixing up "author errors" here, but then we get into a situation where we also "fix up" non-errors... which is not so great.
OK, but in that case we should at least dump a message to the JS console as with other CSS errors.
If the intl code reports the error to us in a useful way (i.e. other than just having an empty stylesheet result), sure.
Seems to be a dup of bug 234502
*** This bug has been marked as a duplicate of 234502 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.