In the example below, IE would attempt to request the file ./url(/css/screen.css) screen, projection—that is, a file named screen.css) screen, projection in a subdirectory named css in a subdirectory named url( below the directory containing the importing style sheet.
@import url(/css/screen.css) screen, projection;
First, it says IE is attempting to request a file “./url(/css/screen.css)” What is this “./” here for?
Second, I do understand it trying to access “screen.css”, but why the end “)”. That is a typo.
Third, this must also be a typo, “…in a subdirectory named url(”
No, it’s not strange at all. Since it believes that the first part of the path is “url(/” it is interpreted as a relative path to a subdirectory of the current directory. The current directory is always “.”, so “url(/” is completely equivalent to “./url(/”.
I think it’s simple: Microsoft incorrectly assumed that the @import directive could only be followed by a URI specification – no media types. They furthermore assumed that the whole at-rule would match a production like this one,
If there is anything other than white space between the url() ‘function’ and the semi-colon, IE seems not to recognise the functional notation at all and believes the whole shebang is a string URI.
So this,
@import url(screen.css) screen;
would have IE looking for a file named “url(screen.css) screen” in the current directory.
I’m not sure how much can be done. The original content is in a special XML-based format called DITA, which is then transformed for displaying on the web. The same source is also used for printing the book (and, I assume, for generating the PDF version).
It’s not really an important bid of information anyway. I wouldn’t actually recommend anyone to exploit this IE bug by naming their style sheet like that. The bug can be used for serving a style sheet to compliant browsers, excluding IE, if you don’t mind getting a lot of 404’s in your logs, but it’s a bit of a stretch.
IE (at least IE7 and older, I don’t know about IE8) does not support media type specifications in the @import at-rule.
If you specify
@import url(/css/screen.css) screen, projection;
IE won’t understand that you’re using the url() functional notation. It will think that everything after the @import keyword up to the final semicolon is a file name. Since ‘/’ characters are recognised as directory separators, IE will believe that the file name is “screen.css) screen, projection” and that the subdirectory specification is “url(/css”, i.e., a subdirectory named “css” in a directory named “url(” (with the bracket!) under the current directory.
That’s why I used the leadning “./” notation: to indicate that it would be a directory under the current directory.
This can actually be used to serve a separate style sheet to IE7 and older! You can create a directory named “url(” with a subdirectory named “css” and then create a style sheet file named “screen.css) screen, projection” with IE-only rules. (Provided that your operating system allows the bracket characters in file names, that is.)
I’m not sure quite what’s happening here. Make sure the @import is at the top of your stylesheet. Other than that, perhaps post a link (or some css) so we can see if the image paths are correct or not.
Actually, I didn’t until you pointed it out.
BTW… and as long as I have your attention… (^_^)
I was reading for a rule for targeting nested CSS rules.
I wrote some rules in “index.php” and targeted background images relative up one level to a global “images” directory. Then I chunked the css into page specific and general css in another directory named “css” one level up from the global images folder…
+ css
|-- general.css //includes part1.css and part2.css with @import
|-- part1.css
|-- part2.css
+ images
|--global_background.gif
+ www
|-- index.php //targeted a background image, now imports general.css
Does @import add another level for targeting? All my background images are broke.
Maybe you can help me understand this since I have to look it up…maybe you’d want to add it to the comments…ehehe
I had too much going on to realized where the trouble was. I had a javascript acting on the named elements in the xHTML file and I was mistakenly believing the CSS was being partially loaded. I wasted a lot of time reorganizing the order of the CSS. This of course only applies to @import rules before CSS, not specific to any individual CSS rule, which I totally forgot in my frustration. And to further complicate matters I had a PHP script operating in the local CSS version and it wasn’t working with linked or imported CSS. And I tried to use !important with @import and this, I guess, doesn’t work.
Too much going on to realize while I was targeting the images correctly; however, they were were in a different folder.
lol
Thanks for your answer. I appreciate the help. I’ll post my editing comments to the correct location.
X
It does seem a bit of a cleanup is needed. Did you notice that you can post comments on the page itself? That’s the place to make comments like this (scroll to the bottom).
Ah, thanks for the clarification, Tommy. It’s much clearer with those bits in red. Perhaps it’s worth amending the page at least by putting the names in quotes or italics, just to make it clearer. E.g.
IE would attempt to request the file ./url(/css/screen.css) screen, projection—that is, a file named “screen.css) screen, projection” in a subdirectory named css in a subdirectory named “url(” below the directory containing the importing style sheet.
