I've been reading up about responsive design and am going to start implementing a new CSS set-up on my site. This has lead me to thinking about the best way to call all these different CSS files. I'll have a different CSS for different screen widths.
I am debating two options:
connecting to all the files from each web page with LINK tags. My only problem with this is the ongoing maintenance (and having to add all these links to start with); I know this isn't the end of the world but seems a little bit intensive on the maintenance side.
the other way would to have just one LINK tag on each web page, pointing at a 'feeder' CSS. This 'feeder' CSS file would include all the links to my other CSS files using #imports. This would mean maintenance would be a breeze. I could add/re-order/delete the CSS files in just one place for the entire site. Great!
However this leads on to compatibility of the #import function [or lack of it in older browsers].
I've looked around and the articles I've seen have been at least a couple of years old.
So, to get to the nub: what percentage of browsers that are being used now [July 2013] support this and can I safely forget about the browsers that wont be able to interpret #import?
If not, what can I do to keep maintenance of CSS files down to a minimum. (Something more elegant than "find and replace on current site").
Instead of worrying about #imports, you should just combine and minify all of your CSS files that cannot be served via a CDN:
<link rel="stylesheet" href="styles-84e599dcbd6c60fa0af76aaa18a5d75f.css" />
It'll load faster, use up less bandwidth, and will work on any browser that supports stylesheets.
There are many ways to do this. If you're not using any web framework (or are using Node.js), take a look at Grunt.
As for your actual question, unless you're planning to support browsers older than IE5.5, #import will work just fine. But I strongly recommend the minified stylesheet approach.
I'm going to actually say that the accepted answer, now in 2016, is not necessarily the correct one-- for a couple of reasons:
1) HTTP 2.0 is becoming the majority-used protocol version in industrialized countries outside of China (thanks, old IE), and will soon be considered the industry standard (if it's not already). This means that support for connection multiplexing and header caching eliminates the need to combine files into one; in fact, at the Fluent Conference in SFO last year the HTTP2 presenter actually argued that splitting things like CSS and images into multiple files will actually be better due to HTTP's superior ability to utilize more bandwidth due to longer connection times.
2) Because of all this front-end automation in CSS like SASS and LESS, you end up much more likely to break the IE 5-9 4095 selector limitation. This is a little known bug because until now people rarely exceeded that number of selectors in a single sheet; however, on enterprise sites this is becoming a common thing. Basically, any sheet with more than 4095 selectors will still be read in, however the browsers will simply silently fail to render any rules after that.
This isn't to say that minifying into one file is bad, however, the other approach of splitting is actually no longer bad either, and in fact, in certain cases is either necessary or even better depending on project needs.
Here are some stats about browsers http://www.w3schools.com/browsers/browsers_stats.asp
For responsive css I would use media queries, it wont affect older browsers, and work great for devices that are going to need the responsive css (mobile devices)
http://css-tricks.com/css-media-queries/
Related
Once upon a time I was thought by more advanced web developers (gee, when was it again? ;)) that we should avoid managing multiple CSS files and stick to one per project. It helped to improve page load speed and avoid silly mistakes when dealing with a lot overlapping CSS rules.
My question is - is this approach still valid?
Argument about page load performance doesn't seem to hold that much nowadays with awesome broadband Internet and clever web browsers with even more awesome caching capabilities.
CSS cascading can indeed be error prone, but just for inexperienced developer and having one CSS style sheet doesn't really make us bullet-proof.
I think that I would prefer to have a set of default style sheets neatly separated by components, then wire them up into one single rule by CSS #import. This would also allow me to include reset style sheet by default.
Anyone is with me?
It's not about bandwidth speed but number of http requests, this makes a lot of sense for a mobile connection.
However the approach of having different css files to keep the project modular is solid, as it helps you keeping your css organized the way you want it without having all the code in one file only. Then you can benefit of css preprocessors / minifiers to concatenate and compress all your css files in a single one for production.
this article http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/
has a paragraph about mobile that explains well why this is a good practice:
you are much better off downloading all of the CSS content in one shot over the initial, warmed up connection. By doing so, you will also help the user extend their battery life. If there is one optimization to be made here then it is simply: concatenate and compress.
Yes, that approach is still valid. There are dozens of articles about load optimization out there, but the general idea is as follows
Less files = less http requests made to server = better load performance
Main thing that changed over time is that now there are many tools that support merging multiple files into single at runtime. So you have separate stylesheets for better organization, debugging at development time, and those tools merge, minify and set correct caching headers at production.
I agree with you, I find no reason to keep only a single css sheet anymore, nowadays, I do exactly what you just stated, separation by component, along with lazy loading :) (php if statements etc).
I separate stuff with comments. For example divs goes to /* Divs start*/ div#somediv /* Divs end*/ /* Animations start*/ /* Animations end*/. For me this is easier than merging different css files once i've completed the project
With new browser enhancements such as CSS3 animations, gradients, SVG backgrounds, etc... it becomes unnecessary for newer browsers to have to download legacy CSS code and for legacy browsers to have to download advanced CSS code. So on a HTTP level (no server-side programming approach) how could you deal with such an issue? Should you have base.css file which is served to both groups of browsers and then have an additional CSS file served afterwards based on which browser group is requesting it? Is there a way to include a CSS file that simply redirects the browser to the browser group specific rewrite? Or is this something that should be figured out and downloaded on the client-side first?
Fully embracing the concepts of graceful degradation and progressive enhancement would allow you to use the same css for all target browsers - in a nutshell, if a browser does not support css3 rounded corners - give it vendor-prefixed rule; if it doesn't support that either - no biggie, the site would still be usable with square corners.
The overhead of downloading rules with vendor-specific prefixes as well as standard ones would be minimal compared to an extra http request and would improve maintainability as well as save you trouble by not having to rely on browser detection.
Layout-specific hacks would commonly have to be applied to IE family only which can be targeted by html conditional comments.
I've found that there are three ways to do this.
Use a big file for each of the stylesheet and javascript assets and then use something like modernizr and feature sniffing to weed out which browser does what. Or just make all the browsers do the same thing. This is better for development input and testing.
Use two files (one called ancient.css and another called modern.css) and use a server-side HTTP sniffer operation to check to see the version of the browser and then provide it with the appropriate file. Set the HTTP caching to expire in the far future to prevent it from accessing the server each time to check to see which file to download. To generate the files, simply just create one file with all of the core stuff shared between all browsers and another with the emulated stuff for the older browsers. The benefit is that you get to use all the new CSS3 and HTML5-JavaScript stuff, but the downside is that you need to test to make sure the modern-browser code stuff works the same as the ancient stuff.
Have two asset files (modern + ancient) and have modern download first. Then have the browser see if it supports something via modernizr and, if not, then have it download the ancient file. The benefit here is that you don't need to have any extra server-side stuff developed, but the downside is that your website will render slower and you may have multiple downloads of the same resource happen at the same time.
I know that there are several very similarly-related questions on this website, however after reviewing the play, I believe this question is unique in its own right. If someone can find and provide evidence of an exact dupe of my question, I will withdraw it myself (so please just don't downvote this!).
I am a Java developer, not a web developer. But, as is the case in so many families where there is one person who becomes the designated family "computer guy", my Java development skills have been mistaken for web development skills, and I somehow got roped into building a website for my parents to help them sell their house.
So, like any web development newbie, I wrote the HTML/CSS myself (by hand, sans editor like DW or Expression, etc.) and tested it against FireFox 3.x. All looked great, and we deployed/launched.
Now we're getting negative feedback from everyone and their dog stating that the site isn't rendering properly in other browsers, browser versions, or on FireFox installations running on different operating systems. Similarly, the site is apparently a total mess when being viewed through a smart phone or tablet device.
Now I could dive in and write a whole bunch of messy, nasty, painstakingly-tedious edits to my CSS rules, that basically say: do X when browser is Y, etc. But I am hoping that out there is a tool that can put all my fears to rest.
What I'm looking for is a tool that could take my valid CSS files, and use them to generate CSS rules that will be compatible with a high percentage of all common browsers/versions.
Alternatively, if I have to re-write my CSS from scratch, it would be nice to have a tool that allows me to write/design once, deploy many, so that I only have to focus on the design of a single CSS file, but the code that gets generated is multi-browser compatible.
It sounds like DreamWeaver kind of does this, but you have to choose from one of 16 pre-existing templates.
My wife is a graphic designer, and made the website pretty sweet (not cookie cutter). It was a nightmare trying to figure out what CSS rules to use to implement her design. So any tool that forces you to choose between templates is not an option.
Is there any hope for me, or do I banish myself from my family in shame right now?
css is a mess, no way to automatically doing it right. saying that I would say there are tools that would walk with you the proper way.
1. use the meta tag:
http-equiv="X-UA-Compatible" content="IE=8" (encpsulate as a meta tag - SO won't display if I wrote it as a valid tag)
to force IE to render with it's most modern engine, that would solve some problems.
2.begin your css with normalize.css - that would eliminate some of the cross browser problems - because it resets your css (better and more modern the reset.css)
I'll second the GWT if you come from the java dev world. although It's a framework to learn with it's own quirks. another possible web framework is Grails - a nice java/groovy port of the mighty Ror.
Less or Scss won't automatically solve your basic problem - which is browser compatibily - but are a better and simpler way to write css
remember that most css3 properties aren't support equally in all browsers (and in IE almost not supported) - use them only with graceful downgrade option with supported js or css -when Modernizr js library can give you pretty good property support detection for various browsers
don't go dreamweaver - it produces terrible code
use csslint to check for valid css and common css pitfalls
If you must use cutting edge web rendering with html5+css3 elements you should look into chrome frame -that would enable older browser better support of your site - although I believe this may be an overkill for a simple sell-my-house kind of site.
use a css framework to prototype- it would give you better css, good basics and resets and good boilerplate - maybe bootstrap or something similiar (didn't try most of them but the internet is crowded with those.
good luck
Check out modernizr. http://www.modernizr.com/docs/
You want to get into the position of checking for features and not browsers.
Here's an excellent site to check your site with alternative browsers:
http://www.browserstack.com/
Less (http://lesscss.org/) will help you with a lot of CSS3 functions.
However, good CSS code simply works on all browsers. There are some CSS concepts that must always be avoided as much as possible (absolute positioning, excessive floats, using the wrong elements for a task, etc) and your code will work better.
In the many years I have programmed I only needed browser-specific code in the first two years. Then I grew up and learned which CSS code not to use and when it was possible to use them. It has been my experience that properly written CSS code works on all browsers, and if it doesn't it will at least get the basic concepts right (eg. a few pixels may be wrong or some effects, but the site still works well).
Several things come to mind that may help your case:
Forget about IE6, that one will give you trouble no matter how much effort you put into the site.
Make sure you have a good doctype (html5 or xhtml would be good).
Try out html5 reset, it tries to make sure all browsers behave the same.
The aforementioned reset also includes modernizr to bring older browsers up to speed
Finally: accept (some even say "embrace") that different browsers render things slightly different. Getting every pixel exactly the same in each browser will be near impossible.
I hate to put this into the world, but it sounds like you need Adobe Muse.
There is no equal to a good developer who will write clean cross browser code, but if you just want to get the site done check out the beta: http://labs.adobe.com/technologies/muse/
What I'm looking for is a tool that could take my valid CSS files, and
use them to generate CSS rules that will be compatible with a high
percentage of all common browsers/versions.
Unfortunately there's no such a tool and you have to debug and test your website for cross-browser compatibility manually. The best way i've found for cross-browser testing it to install and test different versions of browsers in several virtual machines.
You will also find the following helpful:
Modernizr
Google Web Toolkit
What are the best ways to use LESS for CSS.
Basically should the Devs write a Less File and then have it compile for production
Should I link the LESS code and the javascript file.
Or should I skip the LESS rout altogether and just remake the classes
I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.
I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes.
Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as
<div class="comment dark-shadow round-corners"></div>
Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.
I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".
If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-
I agree with Jonathan, I don't think you should depend on the users browser to render the styles.
I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.
So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.
You don't have to be using node.js for the rest of your app either. I did this in a PHP application.
You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/
I realize this answer is about two years later than the above ones but I think the question is still relevant.
I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.
So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.
The way to use LESS for a production website is to compile LESS files into CSS files.
For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.
If you have multiple CSS files to produce from LESS, you should separate them out.
For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.
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 4 years ago.
Improve this question
Is there any advantage to having a single monster .css file that contains style elements that will be used on almost every page?
I'm thinking that for ease of management, I'd like to pull out different types of CSS into a few files, and include every file in my main <link /> is that bad?
I'm thinking this is better
positions.css
buttons.css
tables.css
copy.css
vs.
site.css
Have you seen any gotchas with doing it one way vs. the other?
This is a hard one to answer. Both options have their pros and cons in my opinion.
I personally don't love reading through a single HUGE CSS file, and maintaining it is very difficult. On the other hand, splitting it out causes extra http requests which could potentially slow things down.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
EDIT:
I found this blog that shows how to combine CSS at runtime using nothing but code. Worth taking a look at (though I haven't tested it myself yet).
EDIT 2:
I've settled on using separate files in my design time, and a build process to minify and combine. This way I can have separate (manageable) css while I develop and a proper monolithic minified file at runtime. And I still have my static files and less system overhead because I'm not doing compression/minification at runtime.
note: for you shoppers out there, I highly suggest using bundler as part of your build process. Whether you're building from within your IDE, or from a build script, bundler can be executed on Windows via the included exe or can be run on any machine that is already running node.js.
A CSS compiler like Sass or LESS is a great way to go. That way you'll be able to deliver a single, minimised CSS file for the site (which will be far smaller and faster than a normal single CSS source file), while maintaining the nicest development environment, with everything neatly split into components.
Sass and LESS have the added advantage of variables, nesting and other ways to make CSS easier to write and maintain. Highly, highly recommended. I personally use Sass (SCSS syntax) now, but used LESS previously. Both are great, with similar benefits. Once you've written CSS with a compiler, it's unlikely you'd want to do without one.
http://lesscss.org
http://sass-lang.com
If you don't want to mess around with Ruby, this LESS compiler for Mac is great:
http://incident57.com/less/
Or you could use CodeKit (by the same guys):
http://incident57.com/codekit/
WinLess is a Windows GUI for comipiling LESS
http://winless.org/
I prefer multiple CSS files during development. Management and debugging is much easier that way. However, I suggest that come deployment time you instead use a CSS minify tool like YUI Compressor which will merge your CSS files into one monolithic file.
Historically, one of the main advantages x in having a single CSS file is the speed benefit when using HTTP1.1.
However, as of March 2018 over 80% of browsers now support HTTP2 which allows the browser to download multiple resources simultaneously as well as being able to push resources pre-emptively. Having a single CSS file for all pages means a larger than necessary file size. With proper design, I don't see any advantage in doing this other than its easier to code.
The ideal design for HTTP2 for best performance would be:
Have a core CSS file which contains common styles used across all pages.
Have page specific CSS in a separate file
Use HTTP2 push CSS to minimise wait time (a cookie can be used to prevent repeated pushes)
Optionally separate above the fold CSS and push this first and load the remaining CSS later (useful for low-bandwidth mobile devices)
You could also load remaining CSS for the site or specific pages after the page has loaded if you want to speed up future page loads.
You want both worlds.
You want multiple CSS files because your sanity is a terrible thing to waste.
At the same time, it's better to have a single, large file.
The solution is to have some mechanism that combines the multiple files in to a single file.
One example is something like
<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />
Then, the allcss.php script handles concatenating the files and delivering them.
Ideally, the script would check the mod dates on all the files, creates a new composite if any of them changes, then returns that composite, and then checks against the If-Modified HTTP headers so as to not send redundant CSS.
This gives you the best of both worlds. Works great for JS as well.
Having only one CSS file is better for the loading-time of your pages, as it means less HTTP requests.
Having several little CSS files means development is easier (at least, I think so : having one CSS file per module of your application makes things easier).
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file
i.e. faster loading pages
There are also some software that do that combining of CSS files at run-time, and not at build-time ; but doing it at run-time means eating a bit more CPU (and obvisouly requires some caching mecanism, to not re-generate the big file too often)
Monolithic stylesheets do offer a lot of benefits (which are described in the other answers), however depending on the overall size of the stylesheet document you could run into problems in IE. IE has a limitation with how many selectors it will read from a single file. The limit is 4096 selectors. If you're monolithic stylesheet will have more than this you will want to split it. This limitation only rears it's ugly head in IE.
This is for all versions of IE.
See Ross Bruniges Blog and MSDN AddRule page.
There is a tipping point at which it's beneficial to have more than one css file.
A site with 1M+ pages, which the average user is likely to only ever see say 5 of, might have a stylesheet of immense proportions, so trying to save the overhead of a single additional request per page load by having a massive initial download is false economy.
Stretch the argument to the extreme limit - it's like suggesting that there should be one large stylesheet maintained for the entire web. Clearly nonsensical.
The tipping point will be different for each site though so there's no hard and fast rule. It will depend upon the quantity of unique css per page, the number of pages, and the number of pages the average user is likely to routinely encounter while using the site.
I typically have a handful of CSS files:
a "global" css file for resets and global styles
"module" specific css files for pages that are logically grouped (maybe every page in a checkout wizard or something)
"page" specific css files for overrides on the page (or, put this in a block on the individual page)
I am not really too concerned with multiple page requests for CSS files. Most people have decent bandwidth and I'm sure there are other optimizations that would have a far greater impact than combining all styles into one monolitic CSS file. The trade-off is between speed and maintainability, and I always lean towards maintainability. The YUI comperssor sounds pretty cool though, I might have to check that out.
I prefer multiple CSS files. That way it is easier to swap "skins" in and out as you desire. The problem with one monolithic file is that it can get out of control and hard to manage. What if you want blue backgrounds but don't want the buttons to change? Just alter your backgrounds file. Etc.
Maybe take a look at compass, which is an open source CSS authoring framework.
It's based on Sass so it supports cool things like variables, nesting, mixins and imports. Especially imports are useful if you want to keep seperate smaller CSS files but have them combined into 1 automatically (avoiding multiple slow HTTP calls).
Compass adds to this a big set of pre-defined mixins that are easy for handling cross-browser stuff.
It's written in Ruby but it can easily be used with any system....
here is the best way:
create a general css file with all shared code
insert all specific page css code into the same page, on the tag or using the attribute style="" for each page
on this way you have only one css with all shared code and an html page.
by the way (and i know that this is not the right topic) you can also encode your images in base64 (but you can also do it with your js and css files). in this way you reduce even more http requests to 1.
SASS and LESS make this all really a moot point. The developer can set up effective component files and on compile combine them all. In SASS you can toggle off the Compressed Mode while in development for easier reading, and toggle it back on for production.
http://sass-lang.com
http://lesscss.org
In the end a single minified CSS file is what you want regardless of the technique you use. Less CSS, Less HTTP requests, Less Demand on the server.
The advantage to a single CSS file is transfer efficiency. Each HTTP request means a HTTP header response for each file requested, and that takes bandwidth.
I serve my CSS as a PHP file with the "text/css" mime type in the HTTP header. This way I can have multiple CSS files on the server side and use PHP includes to push them into a single file when requested by the user. Every modern browser receives the .php file with the CSS code and processes it as a .css file.
You can just use one css file for performance and then comment out sections like this:
/******** Header ************/
//some css here
/******* End Header *********/
/******** Footer ************/
//some css here
/******* End Footer *********/
etc
I'm using Jammit to deal with my css files and use many different files for readability.
Jammit doest all the dirty work of combining and compressing the files before deployment in production.
This way, I've got many files in development but only one file in production.
A bundled stylesheet may save page load performance but the more styles there are the slower the browser renders animations on the page you are on. This is caused by the huge amount of unused styles that may not be on the page you are on but the browser still has to calculate.
See: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/
Bundled stylesheets advantages:
- page load performance
Bundled stylesheets disadvantages:
- slower behaviour, which can cause choppyness during scrolling, interactivity, animation,
Conclusion:
To solve both problems, for production the ideal solution is to bundle all the css into one file to save on http requests, but use javascript to extract from that file, the css for the page you are on and update the head with it.
To know which shared components are needed per page, and to reduce complexity, it would be nice to have declared all the components this particular page uses - for example:
<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">
I've created a systematic approach to CSS development. This way I can utilize a standard that never changes. First I started with the 960 grid system. Then I created single lines of css for basic layouts, margins, padding, fonts and sizes. I then string them together as needed. This allows me to keep a consistent layout across all of my projects and utilize the same css files over and over. Because they are not specific. Here's an example: ----div class="c12 bg0 m10 p5 white fl"/div--- This means that the container is 12 columns across, utilizes bg0 has margins of 10px padding of 5 the text is white and it floats left. I could easily change this by removing or adding a new - What I call a "light" style- Instead of creating a single class with all these attributes; I simply combine the single styles as I code the page. This allows me to create any combination of styles and does not limit my creativity or cause me to create a massive number of styles that are similar. Your style sheets become a lot more manageable, minimized and allow you to re-use it over and over. This method I have found to be fantastic for rapid design. I also no longer design first in PSD but in the browser which also saves time. In addition because I have also created a naming system for my backgrounds and page design attributes I simply change out my image file when creating a new project.(bg0 = body background according to my naming system) That means that if I previously had a white background with one project simply changing it to black simply means that on the next project bg0 will be a black background or another image..... I have not found anything wrong with this method yet and it seems to work very well.