Forum Moderators: not2easy
On the smaller sites I've done, I've managed to keep the CSS below about 300 lines, and it still manageable at that size.
However, I'm now doing a larger site, about 50 pages. I can already see the CSS growing and growing, I'm worried that it will become too big to manage.
I guess what I'm getting at is that every page will have a few unique styles as each page has little extra bits as I'm sure you all understand. The problem is, it's getting to the point where I can't remember which styles are on which pages.
I realise CSS is supposed to be standard so you can change the look of the entire site quickly, but it's kinda defeating itself at the moment.
What's the best way to split the CSS into manageable chunks, without defeating the object, and still make the site easy to maintain? I mean, a huge site like the BBC who have tons of different sections, thousands of pages, you can't tell me they have 1 CSS file, it'd be huge! ;D
I'm thinking something like, page layout in the 'root' sheet along with basic styles, more specific styles for each section on the site, and then page specifics on each page?
So imagine the site has 5 sections, each with 10 pages, you have the root sheet with the layouts, the section sheets with the visuals for that section, and tweaky bits where you need them. 6 CSS files and a few <style> tags?
Has anyone got good experience with larger sites?
#index { font-size: 1.2em; }
#about { color: red; }If you keep your page-specific overrides in blocks in your CSS, with the generic stuff at the top then it becomes easier to read. Of course, you still want to keep as much code generic as possible.
I also do what Fotiman suggests, but tend to reserve it for bigger chunks of the site than a page. For example, if there's a sub-section with different enough styling then I'll write a CSS file for that subsection and link it in as well. But I've found that doing a different sheet for each page ends up being pretty difficult to maintain.
I'd stick with one css file - otherwise you may find it just gets even more confusing.
Why not seperate the style sheet out with comment tags?
Have you seen the WordPress Default theme stylesheet?
That is a large stylesheet seperated into sections, eg layout, lists, headings, using comments.
The more stylesheets you have the slower your page will load, due to increased HTTP requests and stylesheets not cached - once your one stylesheet is cached, that's it. Several will slow loading.
and put page specific styles in the <head>. I try to avoid in-line styles so I don't have to hunt for them. Just my .02 worth.
I agree, the only thing I'd put in a <style> would be some feature that appears exclusively on that page. This is something I find occasionally, I do write as generic as possible, but sometimes generic isn't specific enough!
I also do what Fotiman suggests, but tend to reserve it for bigger chunks of the site than a page. For example, if there's a sub-section with different enough styling then I'll write a CSS file for that subsection and link it in as well. But I've found that doing a different sheet for each page ends up being pretty difficult to maintain.
This is what I was planning on, say one section with a red theme, one with a blue, one with green, but all the same layout.
Would a separate layout sheet be the best option, with the section sheets using an @import? That way still only 1 'include' per HTML file.
I'd stick with one css file - otherwise you may find it just gets even more confusing.
I definately disagree, 1 huge file is more confusing, and more difficult to locate stuff that several sheets, divided into relavant sections. The key is good organisation, and where to split them, which is what I'm trying to find out the best way of doing.
Why not seperate the style sheet out with comment tags
I do, but it doesn't really help if you have 500 lines?
Have you seen the WordPress Default theme stylesheet?That is a large stylesheet seperated into sections, eg layout, lists, headings, using comments
No, never used it. How big is the file?
For me using one stylesheet and seperating it out with comments is simpler than using several stylesheets.
If you have several sub domains or distinct different sections to the site with slightly different branding elements, it might be easier to use different stylesheets.
But if it's a case of seperating heading styles, layout styles etc I'd personally just use the one, in a similar way as the WordPress Default theme does. This might get edited for being too long but here is a portion of the WP Default stylesheet:
/* Begin Typography & Colors */
body {
font-size: 62.5%; /* Resets 1em to 10px */
font-family: 'Lucida Grande', Verdana, Arial, Sans-Serif;
background: #d5d6d7 url('images/kubrickbgcolor.jpg');
color: #333;
text-align: center;
}
#page {
background-color: white;
border: 1px solid #959596;
text-align: left;
}
#header {
background: #73a0c5 url('images/kubrickheader.jpg') no-repeat bottom center;
}
#headerimg {
margin: 7px 9px 0;
height: 192px;
width: 740px;
}
#content {
font-size: 1.2em
}
.widecolumn .entry p {
font-size: 1.05em;
}
.narrowcolumn .entry, .widecolumn .entry {
line-height: 1.4em;
}
.widecolumn {
line-height: 1.6em;
}
.narrowcolumn .postmetadata {
text-align: center;
}
.alt {
background-color: #f8f8f8;
border-top: 1px solid #ddd;
border-bottom: 1px solid #ddd;
}
#footer {
background: #eee url('images/kubrickfooter.jpg') no-repeat top;
border: none;
}
small {
font-family: Arial, Helvetica, Sans-Serif;
font-size: 0.9em;
line-height: 1.5em;
}
h1, h2, h3 {
font-family: 'Trebuchet MS', 'Lucida Grande', Verdana, Arial, Sans-Serif;
font-weight: bold;
}
h1 {
font-size: 4em;
text-align: center;
}
#headerimg .description {
font-size: 1.2em;
text-align: center;
}
h2 {
font-size: 1.6em;
}
h2.pagetitle {
font-size: 1.6em;
}
#sidebar h2 {
font-family: 'Lucida Grande', Verdana, Sans-Serif;
font-size: 1.2em;
}
h3 {
font-size: 1.3em;
}
h1, h1 a, h1 a:hover, h1 a:visited, #headerimg .description {
text-decoration: none;
color: white;
}
h2, h2 a, h2 a:visited, h3, h3 a, h3 a:visited {
color: #333;
}
h2, h2 a, h2 a:hover, h2 a:visited, h3, h3 a, h3 a:hover, h3 a:visited, #sidebar h2, #wp-calendar caption, cite {
text-decoration: none;
}
.entry p a:visited {
color: #b85b5a;
}
.commentlist li, #commentform input, #commentform textarea {
font: 0.9em 'Lucida Grande', Verdana, Arial, Sans-Serif;
}
.commentlist li {
font-weight: bold;
}
.commentlist cite, .commentlist cite a {
font-weight: bold;
font-style: normal;
font-size: 1.1em;
}
.commentlist p {
font-weight: normal;
line-height: 1.5em;
text-transform: none;
}
#commentform p {
font-family: 'Lucida Grande', Verdana, Arial, Sans-Serif;
}
.commentmetadata {
font-weight: normal;
}
#sidebar {
font: 1em 'Lucida Grande', Verdana, Arial, Sans-Serif;
}
small, #sidebar ul ul li, #sidebar ul ol li, .nocomments, .postmetadata, blockquote, strike {
color: #777;
}
code {
font: 1.1em 'Courier New', Courier, Fixed;
}
acronym, abbr, span.caps
{
font-size: 0.9em;
letter-spacing: .07em;
}
a, h2 a:hover, h3 a:hover {
color: #06c;
text-decoration: none;
}
a:hover {
color: #147;
text-decoration: underline;
}
#wp-calendar #prev a {
font-size: 9pt;
}
#wp-calendar a {
text-decoration: none;
}
#wp-calendar caption {
font: bold 1.3em 'Lucida Grande', Verdana, Arial, Sans-Serif;
text-align: center;
}
#wp-calendar th {
font-style: normal;
text-transform: capitalize;
}
/* End Typography & Colors */
/* Begin Structure */
body {
margin: 0 0 20px 0;
padding: 0;
}
#page {
background-color: white;
margin: 20px auto;
padding: 0;
width: 760px;
border: 1px solid #959596;
}
#header {
background-color: #73a0c5;
margin: 0 0 0 1px;
padding: 0;
height: 200px;
width: 758px;
}
#headerimg {
margin: 0;
height: 200px;
width: 100%;
}
.narrowcolumn {
float: left;
padding: 0 0 20px 45px;
margin: 0px 0 0;
width: 450px;
}
.widecolumn {
padding: 10px 0 20px 0;
margin: 5px 0 0 150px;
width: 450px;
}
.post {
margin: 0 0 40px;
text-align: justify;
}
.widecolumn .post {
margin: 0;
}
.narrowcolumn .postmetadata {
padding-top: 5px;
}
.widecolumn .postmetadata {
margin: 30px 0;
}
.widecolumn .smallattachment {
text-align: center;
float: left;
width: 128px;
margin: 5px 5px 5px 0px;
}
.widecolumn .attachment {
text-align: center;
margin: 5px 0px;
}
.postmetadata {
clear: left;
}
#footer {
padding: 0;
margin: 0 auto;
width: 760px;
clear: both;
}
#footer p {
margin: 0;
padding: 20px 0;
text-align: center;
}
/* End Structure */
/*Begin Headers */
h1 {
padding-top: 70px;
margin: 0;
}
On small sites I can use just 1 sheet no problem, but take JavaScript or Perl for example, both of which I am more than competent.
You'd never have all your functions in one file, you'd always group them into function libraries for ease of use, that was you know where everything is.
I was thinking something like this:
root.css - layout and basic visuals
---section.css - section specific, new colour scheme for example(if applicable)
------page.css - anything exclusive to that page (if applicable)
All would @import the one before it, so still only 1 sheet linked into any page.
Any of you guys ever done a site where this structure would fit in?
Would a separate layout sheet be the best option, with the section sheets using an @import? That way still only 1 'include' per HTML file.
Just to make sure you're not confused, you realize that these each @import is still a separate HTTP request, right?
I was thinking something like this:root.css - layout and basic visuals
---section.css - section specific, new colour scheme for example(if applicable)
------page.css - anything exclusive to that page (if applicable)All would @import the one before it, so still only 1 sheet linked into any page.
I have to hand it to you, this sounds like an interesting approach. Lets look at an example...
Your "Products Overview" HTML page might do something like this:
<link rel="stylesheet" type="text/css" href="productsoverview.css">
productsoverview.css might then look something like this:
@import "products.css"
h1 { color: #00f; background-color: #fff; }
And then your products.css might look something like this:
@import "layout.css"
h1 { color: #003; background-color: #eee; }
h2 { font-weight: normal; }
And then your layout.css might look something like this:
body { font-family: arial,sans-serif; }
h1 { font-size: 150%; color: #000; background-color: #fff; }
h2 { font-size: 135%; color: #333; background-color: #fff; }
p { line-height: 1.5em; }
There's still going to be 3 HTTP requests, but this gives the CSS a sort of "inheritance". I don't think I've ever seen it used to this degree. I've seen things like a layout page that imported a typography.css and maybe a nav.css, and then defined other styles in that page, but I don't think I've ever seen this sort of reverse-hierarchy/inheritance used to the extent that you've proposed, and I've been working with CSS for a long time. My initial thought is that this sounds like a fantastic way to organize them. :)
There's still going to be 3 HTTP requests, but this gives the CSS a sort of "inheritance". I don't think I've ever seen it used to this degree
3 requests? So what? The files are tiny, and most larger sites have tons of images here and there, when you count all the separators, border segments, backgrounds, buttons, not to mention all the actual pictures on the page!
this sort of reverse-hierarchy/inheritance used to the extent that you've proposed
I was about to point out that the cascade was the whole point of CSS, I just realised what you meant by reverse, I'm using an inheritance rather than a cascade.
It's nice to think I've invented a new concept for an existing technology! ;)
My initial thought is that this sounds like a fantastic way to organize them. :)
Glad you think so. ok, take this example, it's closer to what I had in mind......
layout.cssbody {
font-family: "Arial", sans-serif;
font-size: 10pt;
background: lightgreen;
}h1 {
font-size: 150%;
}#header {
...
}#sidemenu {
float: left;
width: 150px;
background: lightblue;
border: 1px solid black;
}#content {
margin-left: 160px;
}#footer {
...
}...
other generic stuff
...
That gives us a blue menu, on a green background on the left side. Horrible colours I know, that's why I'm not a designer! This would be the intended default for the site.
products.css@import url("layout.css");
body {
background: black;
color: white;
}h1 {
border: 1px solid lightblue;
}#sidemenu {
float: right;
background: gainsboro;
}#content {
margin-left: 0;
margin-right: 160px;
}
Now, for the products section, we now have white text, on a black background, with a grey menu on the right hand side, but everything else the same.
productoverview.css@import url("products.css");
.caption-that-only-appears-on-this-page {
border: 1px solid red;
}
If that caption was used on other product pages, it would be in product.css, and any other section, layout.css.
On a smaller site it wouldn't make sense to do it, you'd end up with as many css files as html!
What do you think?
There's still going to be 3 HTTP requests, but this gives the CSS a sort of "inheritance". I don't think I've ever seen it used to this degree
3 requests? So what?
Right, I just wanted to make sure you didn't think that it was only a single HTTP request. :)
Overall, I like the strategy you've proposed. Here's the alternative approach that I think people are more familiar with:
In your products overview page, you include all 3 CSS files:
<link rel="stylesheet" type="text/css" href="layout.css">
<link rel="stylesheet" type="text/css" href="products.css">
<link rel="stylesheet" type="text/css" href="productsoverview.css">
Now, the benefit to that approach is that from the productsoverview page, it's easy to see all of the players (where all of your styles are coming from) and might be a little easier to debug without having to follow a trail of CSS files. The cascade is right there and obvious.
With the "Inheritance Model" as you've described, the cascade still exists, but it would require following a trail of CSS files to really determine all of the files that were involved. But it keeps your page markup cleaner (less clutter in the <head>).
I see pros and cons to each method. I don't know if I would call one of them better than the other. But I would imagine some people might prefer the former, and some might prefer the latter. I might try changing my habits to use the "inheritance" model for a while and see how it groes on me. :)
[edited by: Fotiman at 5:51 pm (utc) on June 14, 2007]
I was thinking something like this:root.css - layout and basic visuals
---section.css - section specific, new colour scheme for example(if applicable)
------page.css - anything exclusive to that page (if applicable)
Dabrowski, i'm by no means a css expert, but i did make a website similar to what you describe (using @imports) and it works well for me. However, i stop at section.css and put page-specific styling in the appropriate section, otherwise it becomes too cumbersome to debug css problems (one exception is the forum part of the website which has a 3rd level of css). I think it also depends on what tools you use for maintaining the website. I use a text editor with syntax coloring and global regex search, so it's easy for me to scroll through the file and spot the comments that mark each group of styles, or to find out which pages use a particular style.
I also use a lot of multiple classes, so
<dl class="list list-widgets">...</dl>and
<dl class="list list-links">...</dl>
<div class="inset inset-right">...</div>
<div class="inset inset-left">...</div>
The first class defines basic styling, and the second refines it for stuff like margins, paddings, colors, etc. To me that's where the real inheritance properties of css come into play. Actually i wish css had class inheritance, something like
.list-widgets {
inherit-from: .list;
color: #eef;
} BTW, my root.css contains 700 lines (16k), and the section.css files have an average of 200 lines each. I think i need to trim the root.css file a bit, heh.
root.css ...
---section.css...
------page.css...
I use this same schema, and apply the same logic to how I split up the sheets following the recommmended standards of CSS names, putting relevant styles in sheets by function, which is what you're doing here. I would only make one change: for seo purposes, it *may* be helpful to use something more serpy (or maybe I'm just superstitious:)
my-keyword-root.css ...
---buy-widgets-section.css...
------page-title.css...
... make a general style sheet and put page specific styles in the <head>. I try to avoid in-line styles so I don't have to hunt for them.
But you still have to hunt down the inline head styles. I keep all CSS in a directory of it's own (my_serpy_directory :-) ) and use the above "page.css" so it is easier to locate the styles.
<link rel="stylesheet" type="text/css" href="layout.css">
<link rel="stylesheet" type="text/css" href="products.css">
<link rel="stylesheet" type="text/css" href="productsoverview.css">Now, the benefit to that approach is that from the productsoverview page, it's easy to see all of the players (where all of your styles are coming from) and might be a little easier to debug without having to follow a trail of CSS files.
If you can't remember straight away where the given selector is, you still have to look through the same files though, so not much difference really.
Borntobeweb:
Dabrowski, i'm by no means a css expert, but i did make a website similar to what you describe (using @imports) and it works well for me.
Glad to hear that.
The first class defines basic styling, and the second refines it for stuff like margins, paddings, colors, etc. To me that's where the real inheritance properties of css come into play. Actually i wish css had class inheritance, something like.list-widgets {
inherit-from: .list;
color: #eef;
}
I try to stay away from it, but do use them for fonts sometimes, like
class='big green ul'. That's an interesting concept, class inheritance, I suppose in a way it's only a continuation of the inheritance model. I wonder if we'll see anything like that in CSS3.
Rocknbil:
Man, 700 lines! I get antsy when it goes over 200. :-)
LOL! Me too, hence this thread!
I use this same schema, and apply the same logic to how I split up the sheets following the recommmended standards of CSS names, putting relevant styles in sheets by function, which is what you're doing here. I would only make one change: for seo purposes, it *may* be helpful to use something more serpy (or maybe I'm just superstitious:)
Again, glad to see this method has been tested and it works. As far as I'm aware though, spiders ignore css files? I thought they only took notice of images and links? I usually abuse my alt tags for that reason!
I keep all CSS in a directory of it's own (my_serpy_directory :-) ) and use the above "page.css" so it is easier to locate the styles.
I prefer a file structure to mirror the web structure, for example:
webroot\index.shtml
webroot\root.css
webroot\section1\index.shtml
webroot\section1\section1.css
webroot\section2\index.shtml
webroot\section2\page.shtml
webroot\section2\page.css
That way the files are also organised logically. Just my take on it, I find it easier that way. Also I'm building a JavaScript 'You are here' script which will rely on this structure!
.
.
Well, overall I'm glad to see this method works, variations noted. It will make the site I'm working on currently much easier. I didn't want to go ahead and try it - it would have been a lot of work if it didn't work!
Some of you will know from previous threads that I am fairly new to 'the CSS way', just about got the hang of it on single/few page scenarios, time to take it to the next level!
I'm coding the site nicely with this structure, and I have to say it's working really well. Although I do have more CSS files than I thought I would.
Currently, I have my layout.css file, every section has some uniqueness, and some standardness, so 1 css for every section, and most pages have some specific styles, text or image positioning, a <table>, or a div with a background. I've put these in CSS files too, rather than a <style>, the markup is cleaner that way, easier on the eye.
The result, I've found I have a lot of CSS files. Probably as many as shtml, maybe a couple more. However, the files are small, my root CSS is only 200 lines, mostly the standard page header/menu/footer stuff, some defaults, and global things like font colours and sizes. Each section CSS is pretty small, less than 30 lines, just redefining a colour, or menu width. Each page CSS depends on the page, but no more than 40.
Although there are loads of files, no one page refers to more than 3 in this structure, so following the files backwards, and because they're so small, it's dead easy to find selectors and styles.
I'm very impressed with this method. I'd like other oppinions, pros, cons. Please nobody point out 3 HTTP requests, who cares? ;)
One if your page changes but the CSS doesn't the client won't have to reload the CSS in addition to the X/HTML.
You can keep the main and per-page CSS separate and also override some main CSS by redeclaring it in your per-page CSS.
When you link multiple stylesheets it can be a little tricky.
<link href="main.css" media="screen" rel="stylesheet" type="text/css" />
<link href="page1.css" media="screen" rel="stylesheet" title="Classic Theme" type="text/css" />
<link href="page2.css" media="screen" rel="stylesheet" title="Classic Theme" type="text/css" />
Not that you need three style sheets but I decided to include a third for you to detect the pattern here. That pattern is that the main style sheet should not include a title where as all related (to be used when loaded) style sheets should have a title. They also must all be the same titles (which I don't personally like).
Remember the C in CSS stands for cascading. So once something is declared it can be overwritten afterwards (in the left-to-right top-to-bottom sense). So if you want to change the color of say span.example but you don't need to change the font-family for a specific page just declare a new color in page1/2.css. You can override your override on page1.css by declaring it a third time on page2.css. Hope this makes sense. This is exactly how I would approach your goal. :)
- John
Oh ok...looking at it now with a little more depth I would recommend multiple stylesheets. There are a few benefits to this...
When you link multiple stylesheets it can be a little tricky.<link href="main.css" media="screen" rel="stylesheet" type="text/css" />
<link href="page1.css" media="screen" rel="stylesheet" title="Classic Theme" type="text/css" />
<link href="page2.css" media="screen" rel="stylesheet" title="Classic Theme" type="text/css" />
Look in a little more depth! ;)
I'm not linking in multiply stylesheets. Each HTML (no X please) page only links in one.
Remember the C in CSS stands for cascading. So once something is declared it can be overwritten afterwards
Yeah, I know how it works.
Glad you think it's a good idea.
As far as I'm aware though, spiders ignore css files? I thought they only took notice of images and links?
And 'cos each page has it's unique stuff, no repetition of names, selectors, specificity problems, it's just sooo much cleaner.
I asked the SEO question in the other forum, 1 guy replied and said he didn't know. That's all, so I guess it's no.
My situation is slightly different, I think 700 lines is tiny! I work on a site with about 3000 lines of css, but each attribute is on the same line, so more like 14000 lines.
Think about this:
The site I work on has about 200 page templates, (millions of pages in G) with multiple different ways they can display, there's 40 POS in 30 languages, supporting 2 different brand styles. We are currently looking at supporting right to left languages too, and creating an AB testing platform. Now, all this is using the same html, css and js. I’ve got a few tricks up my sleeve that I want to try but I would like to get some info about how others manage sites on this scale?
I currently looking at creating all modules on each page in a standalone way and dynamically generating a css for each page.
Anyone know of any books or articles on the subject of large site css strategies?
I think 700 lines is tiny!
It's huge :) ...for one file!
you mention 'modules' are you using a CMS, or managing a site that has different levels of control?
personally I know CSS inside out, and could optimise, strip whitespace etc.. but when integrating that knowledge with a pre-existing CMS then it doesn't always go to perfect plan does it, I wouldn't want to search/replace 700 lines!
I've been working with a site recently where mostly I can incorporate my limited php knowledge with "add a few lines to the cascade instead", then I weigh up which one works best for the client rather than what is "optimal CSS".. I've come across one "module" where the cascade overrides did not merit all the extra lines (about 40) of code it needed for me to apply the site theme, so I modified the (PHP) module instead, and now I actually have about 20 lines less of CSS than there was in the original download.
it's all a question of balance, IMVHO
