Whether CSS is accepted without a Content-Type is dependent on the doctype of the including HTML, and what version of WebKit you are using.
For chrome 1.0 versions, quirks and transitional doctypes _will_ allow inclusion of such CSS. However a strict doctype will not. (So I am guessing the HTML page you include this CSS on is strict mode). For chrome 2.0 this has changed a little bit. The version of WebKit that we now use, is even more picky about content types, and you will find that transitional doctype pages which were allowing such CSS before, will not work anymore. In fact we hit this exact same problem, because some of chromium's CSS was being served as "text/html" :-) http://code.google.com/p/chromium/issues/detail?id=4181 I don't know the history behind this particular change, so if may be worth bringing this question up on http://bugs.webkit.org by filing a compatibility bug (since it sounds like WebKit is clearly the odd one out in this particular case). In the mean time, I recommend serving your CSS with "text/css". Barring that, change the doctype to be quirks mode. On Thu, Jan 29, 2009 at 5:52 AM, stephen friedrich <[email protected]> wrote: > > I am developing a web application (Java Server Faces). > When testing I found that my app works fine on IE 6, IE 7, FF 2, FF 3, > Safari and Opera. > However Chrome simply ignores all my style sheets. > > In the "Resources" view of the developer tools I get lots of warnings > "Resource interpreted as stylesheet but transferred with MIME type > text/plain." > which is incorrect in two ways: > First I did not sent a response with MIME type text/plain, but a > response _without_ a MIME type ("Content-Type"). > Second Chrome is _not_ interpreting the stylesheet at all. > > I get a similar warning for JavaScript files, but they do work in > spite of the warning. > > It may be important that I sent the response gzipped. > See below for an example response in raw format (serving Yahoo's reset > css). > > To be fair I have to say that I am using SRWare Iron (1.0.155.0 > (6886)) rather than the original Chrome build, but I doubt that that > makes a difference. > > HTTP/1.1 200 OK > Server: Apache-Coyote/1.1 > Expires: Wed, 29 Jan 2020 14:48:43 GMT > Content-Encoding: gzip > Content-Length: 789 > Date: Thu, 29 Jan 2009 13:48:43 GMT > > /* > Copyright (c) 2008, Yahoo! Inc. All rights reserved. > Code licensed under the BSD License: > http://developer.yahoo.net/yui/license.txt > version: 2.6.0 > */ > html{color:#000;background:#FFF;} > body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,textarea,p,blockquote,th,td > {margin:0;padding:0;} > table{border-collapse:collapse;border-spacing:0;} > fieldset,img{border:0;} > address,caption,cite,code,dfn,em,strong,th,var{font-style:normal;font- > weight:normal;} > li{list-style:none;} > caption,th{text-align:left;} > h1,h2,h3,h4,h5,h6{font-size:100%;font-weight:normal;} > q:before,q:after{content:'';} > abbr,acronym {border:0;font-variant:normal;} > /* to preserve line-height and selector appearance */ > sup {vertical-align:text-top;} > sub {vertical-align:text-bottom;} > input,textarea,select{font-family:inherit;font-size:inherit;font- > weight:inherit;} > /*to enable resizing for IE*/ > input,textarea,select{*font-size:100%;} > /*because legend doesn't inherit in IE */ > legend{color:#000;} > del,ins{text-decoration:none;} > > /* SF: from the README: > Beginning in Opera 9.5, a padding value of 0 on radio > buttons and checkboxes prevents Opera from rendering > their visually attractive checkmarks and filled circles > for the radios. This has NOT been addressed in 2.6.0, > however you can apply this patch if you desire: > */ > input[type="checkbox"],input[type="radio"] {padding:1px;} > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss -~----------~----~----~----~------~----~------~--~---
