This question already has answers here:
Difference between #import and link in CSS
(7 answers)
#import vs link
(1 answer)
Closed 5 years ago.
Ok, I've heard a million ways about how to optimize a website's load speed: The fewer HTTP requests, the better (that's why image sprites were born); Inject only the JavaScript files one page exclusively needs. Use CSS for visual enhancements as much as possible, then maybe consider SVG graphics (although this one is still debatable); compress your CSS and JavaScript files and HTML markup; consolidate your scripts into one single file (fewer HTTP requests back again); gzip your assets; etc, etc.
But today I find this comment on a website:
"Since we care about web development best practices, we don’t use #import rules in our projects anymore."
To clarify, my question IS NOT about the difference between:
<link rel="stylesheet" href="file.css"> vs. <style type="text/css">#import url("styles.css");</style>
Is about the difference between adding this to your HTML document: <link rel="stylesheet" href="file.css"> vs. adding this #import url("styles.css") INSIDE your main CSS file.
So, what is the difference between loading CSS files from the HTML from loading files from another CSS file?
I mean, HTTP requests will still be there, they're just being made from different locations.
I read Steve Souders' don’t use #import article, and About.com's article What's the Difference Between #import and link for CSS?, but they compare the methods I mentioned above I wasn't referring to, so it wasn't clear to me why not use #import.
BTW, I don't care about Netscape 4 or IE6 (Thank God I can say that now) or IE7 and the FOUC.
Thanks in advance.
The difference comes down to parallel downloading. #import blocks parallel downloading. This means the browser will wait to import the imported file before downloading the next file.
The first article you cited (Steve Souders' "don't use #import") specifically addresses the case of an #import inside a stylesheet imported through <link> — it's just as bad for performance as putting the #import inside a <style> tag. In fact, it's a little worse: the browser first has to fetch the linked stylesheet, then parse that stylesheet, then discover the #import rule, then fetch the imported stylesheet.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Right now I just got two CSS files in between my <head> tags:
<link rel="stylesheet" href="/stylesheets/init.css">
<link rel="stylesheet" href="/stylesheets/layout.css">
In init.css I reset elements and define certain elements for consistency through most browsers.
In layout.css I basically got everything else.
Now it's a big hassle when developing and scrolling back and forth like a madman. So I decided to seperate the big layout.css into smaller files for better usability and developing. Only I'm not so sure how I would go about separating them.
I'm thinking about something like:
<link rel="stylesheet" href="/stylesheets/init.css">
<link rel="stylesheet" href="/stylesheets/signup.css">
<link rel="stylesheet" href="/stylesheets/navigation.css">
<link rel="stylesheet" href="/stylesheets/upgrade.css">
<link rel="stylesheet" href="/stylesheets/content.css">
... etc.
But for some reason, I feel that is not really the way to go about it.
Could somebody tell me if this is a good approach or if you have a better way I am interested to know about it.
the approach is good, however you may want to concatenate (and eventually minify) your files for the production environment, into a single file. This will reduce the number of requests to one from N.
CSS preprocessors like less and sass and other tools like Grunt etc can also concatenate the files for you even when you are in development, so you can keep your files nicely separated but have only one loaded on your site, for performance reasons.
You are heading in the right direction, it is good practise to split your CSS. There are various ways to do it but most people either use a build script and/or a preprocessor. Using a build script lets you concatenate and minify the CSS as well as JS and HTML.
Preprocessors, such as SASS and LESS, do the same (although only for CSS) but also allow you to write extra logic code that is compiled down to CSS.
That's a brilliant approach. Most programmers split up their css into sections like you to make it easier for them to edit a particular part of the website. For example theme.css would edit the background image and change themes, whereas footer.css would change the footer. However if you don't like what your doing use a processor like SASS or LESS.
Splitting your CSS into several files makes them a lot more manageable and increases usability for your developers. However, it will force every user to make an additional request to your server for each seperate CSS file and forces you to update your HTML code whenever you want to add / remove / rename a specific "group" of CSS.
Native CSS allows you to include other CSS files directly, so you could go the route of having one central "main" CSS that loads all the other styles:
<link rel="stylesheet" href="/stylesheets/main.css">
And in the main.css:
#import "init.css";
#import "signup.css";
#import "navigation.css";
#import "upgrade.css";
#import "content.css";
This will keep all CSS-related grouping in a CSS file itself and out of the template code, but doesn't change the fact that a user now has to request a couple of different files where there was only one before.
An even better solution would be to use a CSS Preprocessor like SASS/SCSS, which allows you to include CSS files automatically and renders them (even with a smaller file size) in one single CSS file while maintaining individual source files on the development side. The above import code would look like this with SCSS:
#import "init";
#import "signup";
#import "navigation";
#import "upgrade";
#import "content";
You would then put all your "init" CSS rules in a file called _init.scss and run the SCSS preprocessor with scss -t compressed main.scss main.css. This renders everything inline into a single main.css file, ready to be delivered to your users via a single request to your server.
On this site http://gaeilge2013.ie/ some stylesheets are not loading in IE9. In Chrome / Firefox / Opera / Safari it's all good. Very strange.
This is the css which is not applying:
<link rel='stylesheet' id='dzs.timelineslider-css' href='http://gaeilge2013.ie/wp-content/plugins/dzs-timelineslider/timelineslider/timelineslider.css?ver=3.5.1' type='text/css' media='all' />
Link is good. ...
Thanks!
The problem you have is due to a limit that IE imposes on the number of stylesheets. IE can only load a maximum of 31 separate CSS files in a single page.
There are plenty of references for this one the web, but here's one from MSDN
This is a hard limit in IE. It is possible to load more CSS files than that by using specific techniques: if you use #import to load CSS files from inside others, it is possible to import up to 31 files for each of the 31 main CSS files. But it's not an ideal solution.
In general, it's better to reduce the number of files if possible -- each file that loads is a separate HTTP request, and having large numbers of requests can have a significant impact on page load performance.
My suggestion would be to try to combine the large number of CSS files you have into fewer files. This shouldn't be a difficult task, but there may be WP plugins you could use that would do this for you automatically if necessary.
You can use Modernizr for fixing this issue. It is a powerful crossbrowser javascript plugin that fixes all those special cases as for the multiple IE versions as for the rest of the browsers.
I leave you the link here so you can take a look:
http://modernizr.com/docs/#installing
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Difference between #import and link in CSS
I've read about CSS #import as a bad practice, and was wondering about the methods I'm using.
I'm currently building a website using WordPress, which imports each plugin's stylesheets by link references, and the main stylesheet is linked in the same manner, however, the main stylesheet currently contains several #import declarations, which I believe I should be moving into the header or into the appropriate pages that they're used in (having two of them are only used on certain pages).
Are my concerns justified, and what are the implications of using those #import declarations?
The web provides a lot of information about this topic, I suggest reading:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
#import vs link
#import or <link> for importing stylesheets?
I think you should use LINK for simplicity—you have to remember to put #import at the top of the style block or else it won’t work. It turns out that avoiding #import is better for performance.
link
Linking is the first method for including an external style sheet on your Web pages. It is intended to link together your Web page with your style sheet.
import
Importing allows you to import one style sheet into another. This is slightly different than the link scenario, because you can import style sheets inside a linked style sheet.
The most common reason given for using #import instead is because older browsers didn't recognize #import, so you could hide styles from them.
This link will solve your all queries
What's the Difference Between #import and link for CSS?
Using the import rule is not bad practice in itself. You just have to keep in mind that imports are only handled after the file including them has been downloaded. So if you have a bunch of files with these statements it can take rather long for your audience to see the css applied.
Each #import statement creates a new http request since it happens client side. So from this perspective you are hurting visitors with slow connections like mobile visitors on Edge or 3G.
A rule of thumb I hear a lot is to merge all CSS that you need instantly and only use #import for things you need later on.
It is best to NOT use #import to include CSS in a page for speed reasons.
importing allows you to import one style sheet into another. This is slightly different than the link scenario, because you can import style sheets inside a linked style sheet. Older browsers didn't recognize #import, so you could hide styles from them, It is the reason for #import.
check this:
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/
css #import
I recently came across a use of the #import rule on Coda.com. They're actually using to import the main style sheet for the site, specifically the format:
<style type="text/css" media="screen">
#import url(./coda.css);
</style>
Which will hide the rules from Netscape 3 and IE 3 and 4. Since a web development tools primary audience will be using modern browsers, what other reasons would there be to use this rather then a link?
None. Using a <link> element also has the advantage of getting rid of the FOUC.
EDIT: Using #import in another stylesheet (.css file) can be used like an #include in C, but there isn't any reason to use #import in a <style> block.
For Coda's site, I'd imagine they did that more out of force of habit rather than any pressing technical need.
#import statements inside of actual CSS files (not in a <style> element in HTML) serve many purposes, such as making it easy to swap in and out other CSS files. The Blueprint CSS framework does this to let you easily remove certain portions of the framework such as the typography stuff or the grid stuff.
Of course, in a production environment, using a bunch of #import statements is frowned down upon because it increases the number of files a web browser has to pull down.
The only reason to use this rule today is to make your CSS more modular by splitting it into different files, like libraries.
So, while your page might link to one stylesheet, that stylesheet can #import other stylesheets for reset, typography, etc.
However, this does slow the loading of your page since it's just more sequential http requests.
I agree with Andrew. I also use imports to split out my css logically. Personally I like to split them out in 4: reset, structure, typography, general (bgs/borders etc)
Depending on the person doing it, their style and preference, css files can also be split out by page section eg header.css, footer.css etc.
One extra thing I do however to avoid the multiple http requests is have a build process which merges (in order of import) and compresses the css files for live deployment.
Hope this helps
I use a modular development approach myself, and often end up with 10+ individual CSS files. As you know, that's a pretty drastic number of HTTP requests, so I like to use Blender.
Blender is a rubygem that consolidates and minifies any number of CSS files into a single stylesheet. It also works for JavaScript.
You can define #media in your individual stylesheets to only serve the appropriate rules to the correct device types.
Can someone explain what are the benefits of using the #import syntax comparing to just including css using the standard link method?
As the answerer said, it lets you split your CSS into multiple files whilst only linking to one in the browser.
That said, it's still wasteful to have multiple CSS files downloading on high-traffic websites. Our build script actually "compiles" our CSS when building in release mode by doing the following:
All CSS files are minified (extra whitespace and comments removed)
We have a "core.css" file that's just a list of #import statements; during compilation, each of these is replaced by the minified CSS of that file
Thus we end up with a single, minified CSS file in production, whilst in development mode we have the separate files to make debugging easier.
If you use <link>s in your HTML files, all those files have to keep track of all the CSS files. This obviously makes changes and additions (both for CSS and HTML files) harder.
Using #import, you reduce a theoretically infinite number of changes down to one.
#import allows you have an extensible styesheet without having to change the html. You can link once to your main sheet and then if you want to add or remove additional sheets your html doesn't change.
Also, more smaller files help the browser do better caching. If you make a change in one part of a large sheet, the entire sheet must be downloaded again for every user. If the styles are separated into logical areas among a few sheets, only the file containing the part that changed needs to be downloaded. Of course, this comes at the cost of additional http requests.
One other handy bit, although pretty outdated, is that Netscape 4 couldn't handle #import, so it is a good way of serving a stylesheet to NS4, then having another stylesheet for more modern browsers that was imported in a standards compliant way.
#import is CSS code. <link> is HTML code. So, if you want to include stylesheets in other stylesheets (or if you can’t change HTML), #import is the way to go.
According to the CSS spec, all #import declarations must appear before any style rules in your stylesheet. In other words, all at the top of your stylesheet
Any #import declarations that appear after style rules should be ignored. Internet Explorer has never respected this; I believe other browsers do. This makes #import a bit less useful, because rules in a stylesheet that’s imported will be overriden by rules of equal specificity in the importing stylesheet.
It allows you to keep your logic CSS file spread over multiple physical files. Helps in team development, for example. Also useful when you have a lot of CSS files that you want to separate by functional areas (one for grids, one for lists, etc), let have accessible in the same logical file.
Say you work for Massive Dynamics, Corp.. It has a Widgets division. The Widgets division has an Accounts department. Accounts is divided into Accounts Payable and Accounts Receivable.
Using #include, you start the website with one top-level global.css stylesheet, which applies to everything.
Then you create a second stylesheet, widgets.css for the Widgets division. It #includes the global one, and its own styles (which can over-ride the global styles if needed, because of the Cascade). Then you create a third accounts.css for Accounts. It #includes widgets.css, which means it also includes global.css. Lather, rinse, repeat.