I received a question the other day from someone who was curious how I handle multiple different page styles and layouts across one site with CSS. It’s a very common scenario I think. For example, you have a homepage that is different from your blog post pages that is different from your about page that is different from your contact page.
Here are some considerations:
There should always be one main stylesheet
In all liklihood, there is quite a bit of similarities across the sites pages. Probably even common elements like header, footer, and navigation. Typography is likely to be fairly consistent across all pages (if it’s not, you should definitely have a good reason for that). There is probably one layout that is the most common across all pages. These things belong in a main stylesheet can be loaded on ALL pages.
How different are the different pages? And how many are there?
Say the contact page has a contact form on it. This form has special styling on it and it’s not used anywhere else on the site. It seems wasteful to me to include all this styling in the main CSS file. That is a bunch of CSS that will be loaded on the 99% of pages that don’t need it. Is there a lot of pages like this?
Unique pages, unique CSS files
My personal style in these situations is to load the main stylesheet on every page, and then, if needed, load an additional stylesheet that is unique to that page (or that “type” of page).
Arguments against
Not everyone will agree with this method. Many people say that every web page should have exactly one CSS and JavaScript file. That means less HTTP Requests and a faster page, right? I think that’s true a lot of the time, but when it comes at the cost of bigger-than-necessary files, then what? And when you also consider it’s a blow to organization, I think multiple CSS files is worth it.
Why I think this works
In the vast majority of cases, you won’t have 100 different layouts. If you do, you should probably take a step back and re-think what is going on on this site. If you really do need 100 layouts, you should be looking into a grid-based framework. I would never advocate creating 100 different unique stylesheets for each of those pages. That is beyond the realm of reasonable sustainability and against the spirit of CSS. But for many many websites with a handful of different page styles and a couple of oddballs, this is certainly my favorite method.
I would agree with this. I am just recently starting to use seperate stylesheets for separate elements such as fonts, layout, misc. I have not thought of doing a separate stylesheet per each page. I tend to wonder how much of a difference it really makes, especially with broadband being so dominant now. Is there really a tremendous impact to have some extra classes loaded onto a page that doesn’t reference them? If so, in what areas besides load times?
I generally use a single, master style for the entire site, and then spin off individual elements (such as forms) into page-specific style sheets. This usually means that on only a few pages there’s an extra HTTP request; that is generally a more efficient use of bandwidth than loading page-specific styles on pages that don’t use those styles, especially when you have multiple pages with unique formatting.
That’s exactly what I had in mind when reading this article. styles.css, along with forms.css, etc.
good post, this is what I have been doing and was wondering if including everything in one file was the better option – I didn’t like the idea of loading custom form info for pages that didn’t need it.
That’s an coincidence! I just applied this trick for a project I am working on.
And I tell you… it helps big time!
If you have CSS that is unique to a specific page, isn’t that what embedding styling is for? Thats seems more organized to me, because if you move that one file that has its own style sheet, you have to remember that it has to go with it.
I agree with having a global style sheet that is used for common navigation and typography, like you said. Then, if you had a smaller section of pages that had a similar format (such as the blog in your example), you could add an additional style sheet for that group. But I think it’s more logical to use an embedded style sheet if it only applies to one page, just like you would use an inline style for one element.
Does anyone use embedded style sheets, or do you always either create a unique style sheet or add it to your main one?
I think it’s better to create a separate stylesheet. Even if you are pretty sure this page is a “one-off”, you never really know. If sometime down the line you need a very similar page, you could re-use this stylesheet for that page as well, and maintain the best practice.
I agree with you… in case of a huge app nobody will want to load a 5000 odd line CSS on all pages just to reduce the # of http requests… you will blow up the server bandwidth in that case ;)
If you have 10+ page types this doesn’t work. I prefer to separate the css into layout.css, typography.css, reset.css, print.css, and in some cases separate forms/buttons/etc. into forms.css. Then within each separate them into sections related to page specific styles.
Man that is so true. I see layouts all the time that look different but have NO single stylesheet. It is really sickening.
My answer to this would be to use unique ID tags in the body of each page, then add declarations specific to that page to the site-wide stylesheet.
e.g. To make text inputs bigger on only your “Contact Us” page:
<body id="contactus">...
<style>
input { font-size: 1.0em }
#contactus input { font-size: 1.2em }
</style>
I read about this tip on some awesome blog a while back:
https://css-tricks.com/id-your-body-for-greater-css-control-and-specificity/
;)
— SEAN O
You could also be a bit tricky and use php to change the body’s ID depending on what page you are on, then set the CSS accordingly ;)
I concur. I prefer this body class message unless the design/ layout of the other page is completely different.
This is the method I use as well. I can see using multiple style sheets but I rarely see anyone using this method… but for the ultra organized, it could work.
I have been using that method for quite some time. And the beauty is that you don’t need to use scripting to make this happen, it works with plain html. Of course, organization in the stylesheet is key to keeping everything straight and working properly.
I like keeping everything in the one sheet. It’s just easier to edit and loads quicker.
The difference between page styles is only usually layout, so only a few extra divs to style in the sheet.
I like having multiple stylesheets for modularity during development, but at the same time I prefer to have a single stylesheet in production for performance.
Sprockets solves the problem for Javascript, but I wonder if it will support CSS in the future. A stylesheet version of Sprockets would give us the best of both worlds with modularity and performance as it does for javascript.
Isn’t this the exact reason why there is the @import functionality in CSS? It allows you to import another CSS file from the first CSS file – This allows you thi do exactly what you want (one main CSS file and loads of others that are loaded depending on the page).
@import does allow you to load other CSS files from a single one, but not conditionally as far as I know. How would a CSS file know if it is on the about page or the contact page?
In ExpressionEngine you could use url segment conditionals to let it know which page it is on. Not useful for everyone, but I’m sure other CMSs have similar functionality.
0) { // if page is contact.php
@import “contact.css”;
}
?>
Eh, no php code allowed…
I ment it the other way around:
You have a blog page, which has blog.css which loads “main.css” and “forms.css”. The contact page (contact.css) also loads “main.css” and “forms.css”.
The about page (about.css) only loads “main.css” and not “forms.css”.
The only downside of this (ofcourse) is that you’ll need to add that specific CSS files to those specified HTML files.
the @ import rule, does allow you to centralize the call for style sheets in a single CSS file. Make sure that all your HTML pages to be linked to a single style sheet that will manage the call only to other CSS. So without changing your HTML pages you can disable, delete or add as many stylesheets as you want.
i think it’s all about choices.
i usually try to keep it simple, just one main stylesheet that holds all the generic elements. but if it feels right to form me add another one to the project – i don’t see why not.
keep swinging!
I use this all the time, why load CSS when there is no need for it on a page. I generally do section specific, because I am creating ecommerce sites so its more like a CSS file for product page, Account, and checkout and then the main stylesheet that has all of the general CSS. When your talking about large applications the amount of CSS that could be seperated for page or section specific CSS would be just as bad as the extra request to the server I bet.
In my opinion, I don’t agree with this approach at all, but hey if it works for you then go right on ahead. I agree with Designer. You only want to separate into high level buckets like layout.css, color.css (you missed this one), typography.css, reset.css and print.css
You don’t embed styling into the document no matter what, even if it is page specific.
It really depends on how big a project is as to whether I use this method. More often than not I’ll use a single CSS file and simply use an ID or class on the body and style the page based on that.
If I was dealing with an extremely complex layout where I might have 500 lines of code for a product page template, 500 lines for a category page etc then I’d be more inclined to split these out into separate files so that these could be worked on independently of each other.
In that case, I’d probably find it useful to also have a reset.css file to handle my resets, global.css file to control things like header, navigation, footer and then a product.css and category.css for these complex pages.
Any argument on this topic would never end though as there is no right answer. If it works for you and your team then it’s another tool in the box :)
The @import rule thus allows to keep some things the same while having others different.
For CMS scenarios, it’s usually better to have everything in one stylesheet because of the dynamic nature of the content.
I too was thinking about this today revamping our old site. Subtle changes such as background depending on your landing page. It seems to flow dynamically when you are done with your project and makes it unique.
Chris I’ve styled that one page both in a unique stylesheet and as part of the main stylesheet. I think there’s a balance about when one is a better option than the other. For example if your contact form only needed one line of css it makes more sense to include in the main stylesheet.
This is mostly about understanding the pros and cons. You have to balance the weight of the css for every page with the extra http request on the one page.
Currently i am doing with a single style sheet. This approach is okay. But if some body is editing after sometime.. he may get confused about this. He may trying to edit the main style.css instead of page specific? then this approach may run off.
waste of time doing it!!!
Save some bytes and waste HTTP.
You said:
Many people say that every web page should have exactly one CSS and JavaScript file. That means less HTTP Requests and a faster page, right? I think that’s true a lot of the time, but when it comes at the cost of bigger-than-necessary files.
Can you explain more about “but when it comes at the cost of bigger-than-necessary files”?
I think he ment that, when using 1 CSS file, also stuff from the contact page, about page etc. are loaded while the users is only browsing the blog pages.
The CSS for the contact and about page are useless and make the file “bigger-than-necessary”.
I like having just one stylesheet if possible, but I have had to use multiple stylesheets in the past. It is definitely easier to use just one stylesheet, as everything is in one place, I tend to split my CSS up so headings tags are all together etc – this makes it much easier when you have to go back to edit it, especially if someone else is doing the editing!
It totally depends on the project and the amount of CSS that would need to go into a separate stylesheet. I only do it when there is a considerable amount of CSS that is unnecessary elsewhere. It doesn’t make sense to do it just for a few lines of CSS.
Just a quick question about @import. What stylesheet takes priority over another. For eg. I have structure.css, print.css, reset.css, ie.css.
You could always process the css on the server with php and then send one sheet with only the required stlyes.
@Thomas I tend to do that too. If I’m working on an app, I create a stylesheet for each “section” of the site and then just create one big stylesheet on deployment with whatever language I’m working on.
If I don’t have access to that, I just split up the global.css file into sections. It makes things a little harder to manage because the file becomes so long, but it’s still tolerable.
You can create scripts which will mash together all your css files and minify it, thats the best of both worlds
Agreed. You can organize as much as you want and in the end a combined & minified single css file is sent to the browser.
It is also good to check if any of the combined files changed and then append a get parameter to the resulting minified css (e.g. a timestamp) so that changes are reflected immidiately. Very convinient when you need some urgent fixing and really don’t want to rely on the good will of the browser/proxy to grab the new version.
Yeah, but how do you load additional stylesheets on a specific page?
I understand PHP must be involved in loading the additional stylesheets in the header, but what do you use to define when to load them or not?
Page ID?
load main.css / begin php / if page id is 355 then page must be contactus / echo the link to contactus.css / else if page id is 356 then page must be about / echo the link to about.css / else do nothing / end php
…or Page titles?
load main.css / begin php / if page title contains ‘contact us’ then page must be contactus / echo the link to contactus.css / else if page title contains ‘about’ then page must be about / echo the link to about.css / else do nothing / end php
Today I’m using specific CSS files but they are all loaded in wp header regardless which page is visited.
probably somethink like:
<link rel=”stylesheet” href=”/css/cssgen.php?sheet1=main&sheet2=contact” type=”text/css” >
I would go with page ID since a page’s title could be the same while page ID’s are guaranteed to be unique. I’m assuming you’re talking about WordPress.
In just straight-up PHP: the quickest (but not the best) way to do it would be to get the URL of the page. and print the stylesheet associated with that page.
I use multiple stylesheets for ease of use when multiple “designers” are in play. However, I try to keep the number of files limited. We have a file for layout (I touch it) and content (they touch it). This allows for quick and easy changes for the “content styling” without them affecting the overall layout of the site.
On occasion I’ll throw in another file depending on the number of pages that will pull it…for example “gallery” if there will be a variety of gallery pages.
I always followed this method and I think it’s the best balance betwen speed and organization.
I like this method. With our site we generally have a few main stylesheets that deal with all common details across all pages (layout, typography, theme, header, footer, etc. for example) then we use separate css files for specific pages that have various functionality.
For example, only one page on out site uses the dojo javascript framework’s tabContainer and a specific layout in the “content” section of that page. I made a specific CSS file to accommodate this unique situation.
It’s really there is no totally difference pages in a website. But also there are no pages that is 100% exactly the same. This is one of the enjoyment of working with html editor program like Expression Web. Although css is very helpful in building pages of a website they must be done meticulously accordance with separation and organizing of css amongs the pages.
Separate stylesheets for separate pages make life more simpler, no doubt, thats what I do. But I really like @Lars way – seperate stylesheets for separate elements. Have to try ;)
Good idea
The same schema I use frequently. Sometimes it’s difficult to separte css code, but this way is really usefull.
PD: Excuse my English!
I have to agree with Dave Woods, this argument really cannot be won because there is no right or wrong answer.
That being said, I do find it interesting that no one has bothered to address the issue of images within their css as a determining factor on whether to split into page specific css documents or not.
Consider:
If you use one document to manage all of your site’s CSS, and you’ve gone the route of breaking the document down by body IDs so that each page has it’s own “section” within your 1 css document – yes, you will only have the one http request for the document, and yes, you can use compression tools to minimize the document’s size.
However, you cannot prevent all of the images you’ve declared in your css from loading on the page, even if only a fraction of them are actually required to render the page you are viewing. Each background image defined in your css generates another http request. Even if the images themselves are relatively small, you would still be factoring their weight (in bytes), and the delay of the additional http requests, into the download time of your page (which, in some CMS or Enterprise level Web Application cases could add as much as 60k to 80k total to the page size, compression not withstanding). This overhead would be added to EVERY page on your site, regardless of whether it was relevant to the current page or not, and this would be the primary argument for creating a separate css document for each page.
Typically, we create a global.css document, which encompasses the design.css / typography.css / print.css into one document, along with some highly common generic class assignments that are used site-wide. This allows us to compress and cache this one document, which basically never changes once a site (or in our case, application) is moved to production. Then, page-level css documents are created and named for the page on which they reside, and it’s in these documents that any additional page specific css (including images) are loaded. This document can then be compressed and cached separately, so as not to affect the caching of the main css document. In this manner, we only load the images (and generate the http requests) necessary to render the current page.
As has been stated previously, this approach is more suitable to large CMS development, Enterprise Application development, or Module level development (e.g. widgets, dnn modules, etc.), but I do encourage designers to consider this, even when working with smaller sites. The images declared in your CSS (their size and frequency) have a far greater impact on page performance than the overall character size (in bytes) of the css document, or the additional http request a page specific css document will generate.
David, I sure hope people have the patience to read all the way down to your comment, because you’ve been the first to offer something other than a personal preference. I’d completely forgotten about this little-known behaviour, and can’t thank you enough for bringing it up!
I wonder, is this how every browser behaves, or are there at least some intelligent enough to know which images to load when?
John,
I believe this is the default behavior for all browsers (at least to my knowledge). The only way I can think of that a browser could determine which images to display on a page would require the rendering engine to parse all the HTML and CSS for the page and then only perform the gets for images whose parent CSS classes were found on the page. At that point, however, the browser would have already read the entire CSS document into the page…so I’m not sure how the browser core would handle conditional loading of images at that point, since typically a page is loaded from top down.
It would be interesting to see something of that nature, though we can effectively do that as designers by approaching our CSS development with a little more caution and forethought. :)
I agree with EVula however I think, that it’s also a matter of how big the entire site is. It makes a different if I have a site with thousands of pages or a site with 5 pages. For the last scenario, I don’t think you need 5 stylesheets – I think 1 stylesheet can handle that well.
Good article Chris.
I have to admit that i have been using one master sheet for the whole page for a while, but the file kept growing(i don
t meen the size of the document, i mean the number of css-code lines),and it became harder to maintain the site..So i started with the system you talk about. A sheet for a page.Most of the sheets are nearly identical anyway,so it
s easier to work.And you know how sometimes the changes you make in a sheet(if you are using one sheet for the whole page) are exactly what you need for one page of the site, but they mess something completely different on the other page.Well,when you are using multiple sheets, you don`t have to worry about that.I am not sure if you understand what i mean,i am still working on my English,but i hope you do.Anyway, i suggest to everyone to use this multiple stylesheet system. It helps a lot.
You say that “Most of the sheets are nearly identical anyway”… I just want to verify that anything that is “nearly identical” from page to page should be kept in a SINGLE main stylesheet, and only the stuff that is very different in alternate stylesheets. If each page had a stylesheet that was basically a duplicate with only minor changes, that would be bad.
Separate style sheets are, IMHO, an extra layer of flexibility on content presentation. We could think of it as a variation on csszengarden’s approach: You develop one main stylesheet that has all common elements on it, and then some variations, html code can be the same, but CSS can make it look a bit different, more interesting, kind of what happens with print publications.
If/When used, it would also let you style some elements differently, but also would let you RESTYLE your whole website without loosing certain elements that make sense on this “alt” designs… A seasonal change in CSS might be a good example.
This also opens the possibilities to do much more with content, you might want to offer variations to the article poster (with previews) so they can decide which layout suits better their content (or not and give this power to the content editors / moderators).
I have been experimenting with it (ever since Zikula lost it’s ability to do “multisites”, one has to come up with ways to cope with it) and so far it looks good (admin interfaces used to have the one design usually based from the main site, not anymore. Multiple places on your website can be themed differently, etc, etc).
This implementation would be why I would use several stylesheets: CSS Zen Gargen style. But the thing is: we’re talking about a single site in this instance. If you were doing a site that has a Modular Layout System like on Jason Santa Maria’s personal site, then I can see having a separate stylesheet.
But in current applications, more likely, this is not the case. A unique page may only involve a few changes, maybe a different background, maybe three-column instead of two-column, etc.: this doesn’t take a lot of lines of CSS to accomplish.
There are several scenarios where this would be useful though. A band site would be able using the same HTML have spinoffs to showcase their albums. This in turn would allow them to use a CMS to manage the content for those albums. (www.nin.com is a good example).
A soccer team’s website would be also a good scenario. Think of it as a website that has separate designs for little league, juvenile league, big league. Each one of them has different CSS but could use the same HTML. This also helps the designer target each segment of their audience.
Let’s see how: CSS files would be a general.css site that lays some basic sizing rules, colors and fonts; we would also have a css framework for positioning and from then on we would have separate CSS files for each group of pages of the site we would want to style differently.
IMHO, with this one could use the same basic HTML for any group of pages on the site (this is usually the case with CMS).
My experience with this derives from working with Zikula and the Pagesetter module. With this module you generate custom publications with custom fields. Each publication could need to be treated as a separate section of the same website. You’ll see the need to use this approach once your client expresses the need to have more than 5 publications. Your templates would benefit from the general.css file and the positioning framework, but the rest of the presentation would also benefit from being able to be separable.
Revisions for this way of doing things would avoid classes tripping over each other and could also mean that you can apply faster any changes your client needs on each specific section.
The general.css file (or a branding.css even) could mean that you can also adjust the css for seasonal reasons (fashion design websites come to mind).
Now, i don’t see the point of using this technique with simple websites, or when using simple scripts. But for a really really complex site, I think this would keep sanity (a web portal would benefit with this too).
Just my two cents though.
I like this kind of flexibility both in development and in final result. Certainly over time I’ve moved more towards a multiple stylesheet approach rather than trying to rely on a single large CSS file for a site. It gives significantly more control over page layouts and appearance at very little cost to performance.
It can be more difficult to conditionally load stylesheets with certain CMS. I’ve worked out a reasonably elegant way to do it with Joomla, and I notice from comments above that Expression Engine has the capacity to do so. In a dynamic environment, and particularly when pages are being changed and update by the less technically savvy, having previously set up this kind of styling flexibility can be a great boon.
As others have suggested, I’d favour the single stylesheet in production. I certainly wouldn’t request multiple stylesheets for the home page.
The multiple css images problem is solved trivially through the use of a sprite. I’d be more concerned about the possibly 500ms latency on each http request than adding a few more unneeded kb to a single delivery. At low broadband speeds, you’d need about 2000 lines of uncompressed css to add 500ms to the download time.
It’s going to make subsequent navigation through the site snappier if there isn’t the need to hit the server at least twice on each page.
CSS sprites are only a solution where they can be used effectively. Depending on a design, the use of sprites simply may not be practical. One example would be in using .png images with alpha transparency and shadows. Take, for example, a 4-way expanding box with rounded corners and shadows, with an 4-way internal gradient map. A css sprite will not work here.
In addition, depending on the complexity of the image being used as a sprite, you may be adding a few “extra” bytes to the original image, but you are also adding ALL those bytes to pages that do not even make use of the image. This may not be an issue for a simple 5 page site…(unless the sprite is 30K by itself)…but for larger sites (or modular-based designs, such as portals or complex corporate sites), you typically try to save every kb you can. This includes code size, number of http requests, image sizes, script file sizes, .swf file sizes, etc.
Through the use of page-specific css (even when not using sprites), depending on the complexity of the design / content presentation on that page, a separate document may allow you to save anywhere from 12kb to 60kb of size for that one page. This may not have much of an effect for broadband users, but if this page is being served, say, 100,000 times a month…that 12kb to 60kb adds up in bandwidth utilization, disk transfer, etc. which is all part of the cost of hosting a website.
Also, keep in mind that there are many factors that affect page performance, such as network latency, the demands being placed on the server at the time of page delivery, whether compression is enabled, caching, etc.
As designers (and developers), our focus is on providing the best end-user experience possible, while meeting the goal and vision set forth by our clients. To that end, we must factor in all the various ways in which we can maximize delivery while minimizing overhead. To me, that is much more important than the philosophical debate over 1 vs. page-specific style sheets.
Not everyone has broadband, and not every phone is 3G capable…and with the emergence of the mobile web, it is going to become increasingly important for UI designers to develop smarter and more efficient website designs, and page specific (or modular) css is one way to achieve that.
I always use one master CSS for general layout settings and general selectors used by many pages. For single page or set of pages I always create unique CSS that contains only selectors for specific page.
Generally, I hate that speaking of “user bandwith load” … so what ? Today, everyone donwloads GB’s of datas from internet, so I don’t see 4Kb or 10Kb of CSS as problem …
Hi,
I like your approach but it is kind of difficult to follow when you are creating skins for platform like moodle. You can create different CSS files when it is needed and it is useful for maintenance; but if you register all your CSS files in the config file of the skin, all CSS files are going to be mixed in one big file. So all CSS files are going to be loaded in all pages.
It still being good for maintenance because you know where are the specific styles, but every CSS files is loaded, even if it is not used.
You can go around it and add specific stylesheets when they are needed, but it is not common.
As a personal opinion: I try to separate the CSS files to obtain a logical structure. I helps me to know where is everything. I put it over performance concerns.
Just to know:
separate files are really a big problem for performance?
By the way, thanks Chris for your excellent posts, they help me a lot. They make easier learning for beginners like me.