Some time ago I wrote an article about some peculiar css behavior in Safari 3. We did some more research and came up with some clearer results and four small test pages to boot. The good news is that most recent browser versions seem to have resolved the problem already.
a little recap
To summarize in short, when you link to a css file that isn't really a css file, browsers will do their best to parse it as a css file anyways. If the linked file should contain valid css statements, these will be executed as if the file were really a css file. Unless the file header specifies a 404 error, then this file will be ignored. At least, all browsers seem to do this, except Safari 3.
The problem arose when we linked to a non-existing css file. It returned a 404 page containing inpage styling, which was then applied to the page the file was linked on. This happened only in Safari 3.
illustrating the problem
First off we've made a test page that links to a non-existing css file, returning an error page without 404 header. You'll notice that all browsers will try to parse the returned error page as if it were a regular css file (ignoring the first css rule, as the parser will assume that all preceding html is included in the css selector, making it fail matching any elements):
The second file shows us the same situation, but with an error page containing the needed 404 header. This should look okay in all browsers except Safari 3, where the 404 header is ignored and the styling is still applied:
playing with file extensions
The above examples assume you are linking to a .css file, but now what if you're linking to files with a different extension. Following below are two example pages where we linked to an existing php file instead of a non-existing css file. The content of the php file is exactly the same as the error page returned in both examples above.
The results are pretty clear. Opera 10, FF3, Safari 4 and the latest Chrome are unaffected by this attempt to mess things up. But Internet Explorer will render a different result when picking the page without 404 header, same goes for Opera 9.64. Safari 3 will choke on both examples. These browsers seem not bothered by the different extension and still try to parse the files as css.
Since Safari and Opera are minority browsers and their most current versions already fix the problem this is not really a big issue. Internet Explorer only messes up when the 404 heading isn't in place, which I assume is a pretty rare use case. Still, it's one of those quirky little situations that you won't expect to happen but might give you some very big headaches when they do happen. So consider yourself warned.
Safari 3 ignoring the 404 header is obviously a bug, but the issue with different file extensions is less clear and I don't really know what actions would be advisable. I can't see any logical reason for linking a non-css file as css (and still expecting the css to render), so maybe browsers shouldn't try to parse it as css. On the other hand, if you specified the linked file as a css file, why should your browser go against your wishes. If by chance this method solves a crucial error two or three years into the future, why would you lock it down?
I never ran into any discussions about this before, so if anyone has links, be sure to share them.