Don’t use @import(stevesouders.com)
stevesouders.com
Don’t use @import
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
15 comments
Or more succinctly: "In IE @import behaves the same as using <link> at the bottom of the page, so it's best not to use it." Know and love http://developer.yahoo.com/performance/rules.html
I wasn't even aware @import existed, and I don't really see any redeeming reasons to use it instead of 'link' anyways, as 'link' is "cleaner" and is HTML and thus can reap all the rewards that linked javascript, image links, etc. enjoy. Can someone please explain?
There's nothing "clean" about using a link. @import is an actually useful feature: the ability to define dependencies. "This file depends on another, which I've imported." Instead, using link tags forced you to push dependencies all the way to the top of every project (just like script tags). This is a huge failure of web technologies, and its one reason why all the good frameworks have to include build tools to flatten dependencies.
It's just one of the many cosmic jokes of web programming. We have first-class functions, classes, DSLs, modules and mixins. Unfortunately these features are spread out over three separate languages: HTML/Javascript/CSS.
You can use @import inside an externally linked style sheet mimicking includes.
@imported stylesheets have high precedence over <link>ed ones. If you @import a stylesheet it's as if you typed it inline in the <style> block.
AFAIK, that's the only functional difference
AFAIK, that's the only functional difference
[deleted]
I highly recommend his book (or wait for the upcoming 2nd edition), it is filled with invaluable stuff like this. Really an eye opener for me.
Speaking of, is there a way to import the navigation menu into an xhtml page without php or somesuch? Both "link" and @import are only valid within the header, so they are no good for importing data into the body of the page.
You could do it via JavaScript or iframes, but it's generally a bad idea. Server-side scripting languages like PHP or even server-side includes exist for a reason and fulfil this exact need transparently from the user and there's no good reason to shy away from it.
Fair enough. I was having trouble getting PHP working the other day on my web server, so I guess I need to call my hosting company and ask what's up.
Yes, if you're serving from Apache:
* http://httpd.apache.org/docs/2.0/howto/ssi.html
* http://httpd.apache.org/docs/2.0/mod/mod_include.html
I'm sure other servers have similar options.
* http://httpd.apache.org/docs/2.0/howto/ssi.html
* http://httpd.apache.org/docs/2.0/mod/mod_include.html
I'm sure other servers have similar options.
If you do this, be aware of the security risks associated with SSI.
Read the relevant part of: http://www.w3.org/Security/Faq/wwwsf3.html
Read the relevant part of: http://www.w3.org/Security/Faq/wwwsf3.html
Nginx also supports server-side includes: http://wiki.nginx.org/NginxHttpSsiModule
The original rationale for using @import for including a CSS file in HTML was that Netscape Navigator 4 did not understand the command and thus was an easy, effective and compliant way to exclude that browser, since it had atrocious support for stylesheets. Now that NN is no longer a factor it makes sense to relegate the use of @import to only within a CSS file.
BWT, the screen flicker of IE is eliminated if LINK is used first (say to load a reset.css file) and any subsequent stylesheet loaded via @import behaves as it should.