While this is a great article, it could use more examples. I really hate to see the multiple http request problem not solved. I would just create in PHP (or your language of choice) one file that includes all the others (e.g. using php’s include function) – at least that will reduce the network overhead.
In the past I have merely copied, pasted and modified working CSS from past sites when designing new ones with a similar layout, so moving to a framework is a logical step. Thanks for bringing Yahoo’s UI library to my attention, too – it looks incredibly useful. I look forward to cutting out time working out issues like why my div is 2 pixels to the left in IE and having fun getting back to actually designing!
If you use “TextMate”:http://macromates.com/ , you can specify the default content when creating new files types. For example, you can edit the template that creates new XHTML Strict 1.0 documents to already have the structure you prefer (like including YUICSS links, etc…).
I then use “Snipplr”:http://snipplr.com/ and their “TextMate Bundle”:http://snipplr.com/extras/textmate/ to easily pull in my own code snippets or favorite code snippets. The bundle saves those snippets offline in TextMate, which is useful if I’m coding offline. The combination of TextMate and Snipplr is my framework.
Good article, this is something that I’ve been thinking about quite a bit recently. Most of it seems like common sense, but then all the best ideas do. I agree with Jon Henshaw above with regard to ‘implementing’ this framework.
I have a few core CSS files that I always start a site with:
reset.css (from Eric Meyer)
IE_only.css (to sort out the misbehaving children)
styles.css.
The last one will eventually have all the main styles in, but it starts with some basics that I always use (styles for links, setting font size to 62.5% etc) and then I build on this.
Any common code that I often use is saved as snippets for use with the Scribes text editor. For example I have a nice snippet that creates a tabbed navigation bar within a few keystrokes – it makes development much quicker.
Site-wide blocks like sidebars, navigations and complex forms included after the content section. My ideal positions of the code blocks in the <body> are as follows:
1. Header — contains logo (image) and concise slogan (text) of the site. Header can also contain few links to the most important navigation sections of the site (2-5 links) and breadcrumb trails. It is important to keep this information first for branding and accessibility. This also tells the search engine which pages are the most important.
2. Content — starts with heading 1 and continue with the copy paragraph text, headings (2, 3”¦), unordered and ordered lists”¦ If the content contains semantic blocks, these should be wrapped in a div. Example: information about one product in a group of products should be enclosed in a <div>. This <div> can contain heading with the link to the product page, image of the product and paragraph text with the product description. More information about the content and copywriting has been in the copywriting guidelines document.
3. Secondary content — if you have one, it is usually the non-site-wide navigation specific for the current section
4. Sidebars — should contain site-wide-navigation and all the site—wide search forms and similar stuff. The ideal structure of the navigation is unordered list <ul><li>”¦</li></ul> or nested unordered list <ul><li>Section<ul><li>Subsections</li><li>another subsection</li></ul></li></ul> in case you have sub sections. If the sections contain many other sub-sections, you should put this in a separate list to the secondary content. See ““http://css.maxdesign.com.au/listamatic/”:http://css.maxdesign.com.au/listamatic/ to find out how to give your list-based navigation the look you need.
5. Footer — contains the most generic information. Footer may contain information about author/owner of the page enclosed in the <address> tag. The <address> should contain full address, e-mail and telephone number. You may want to add more semantics here using VCARD format. To include an address is espacially important for local business sites to make the page rank for local terms: “Type of the business and name of the location”? (E.g.: Travel agents Swindon, PPC Warrington) and ensure user can easily find contact details. Footer can also contain link to T&C, Site-wide sitemap and copyright/licence information.
6. Wrapper – Everything is wrapped in the wrapper to make it easier to create which has its position:relative to make the layouts easier with position:absolute
Copy & paste the code below to embed this comment.
Mulyadi Oey
This is a good article. Thank you.
My main concern is that how are we going to communicate the existing styles to the other designers for reuse? More often than not, the styles do not get reused simply because they are hard to find. Should we create some sorts of documentations (e.g. screenshots) for every major style?
This is a great article to get us thinking. I really like the idea of standardizing our approach to CSS.
To your list of 5 basic style sheets I might add one for microformats since there are some basic styles I generally end up applying to them and the classes are 100% predictable.
I worry that class names like “tabs” aren’t semantic. I haven’t played around with it myself (I have a full time day job maintaining one site) but I’m wondering what your thoughts are on starting with a predictable basic XHTML layout that has common semantic class/id names in it like a header area with a nav list in it by default and then grabbing an applying different basic style sheets (or parts of sheets) depending on how you want those formatted.
Copy & paste the code below to embed this comment.
LeMel LeMel
On HTTP connections vs. stylesheet size, what’s wrong with using @import in a CSS 2.0 world? Cascading is supposed to be a core feature—it’s the ‘C’ in CSS after all.
For the framework I built for our developers, there is a basic.css. More advanced stylesheets import the BASIC.css. Some have multiple imports to other css ‘modules’, for example, TOOL.css imports BASIC and GRID (GRID imports TABLE), while GUIDE.css which doesn’t need GRID only imports BASIC and TABLE.
As long as you keep the functionalities simple and nested, developers only see a few choices (TOOL, GUIDE), and the cascade logic takes care of the rest, while giving me the ability to add new modules or styles only where needed without steadily increasing BASIC.
I’m sure some more advanced folks will let me know why this is bad somehow, but it has worked here for a few years in our (admittedly homogenous) environment (an intranet).
As many others, I really like to keep it minimal. But even at minimal, I tend to use at least three CSS files. Basics, IE fixes and then the rest. I’ve never used a framework and probably never will. Good article tough, many points i’ve not know of. Thanks!
I know it’s been a while since you’ve written this article, but I wanted to tell you thanks for taking the time to share your experience. We have been getting a lot of requests for larger MVC sites that are very complex from a GUI perspective (not to mention the programming aspect), and we are definitely seeking an optimal approach with our CSS and designs, as we’ve been spending a lot of time looking at each other’s CSS and going, “huh?” and “what the …”.
You said:
Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well.
Actually Google Pagespeed project supplies code that can be used to flatten and minify your css into a single request.
55 Reader Comments
Back to the ArticleJoseph McMurry
While this is a great article, it could use more examples. I really hate to see the multiple http request problem not solved. I would just create in PHP (or your language of choice) one file that includes all the others (e.g. using php’s include function) – at least that will reduce the network overhead.
Mathew Browne
In the past I have merely copied, pasted and modified working CSS from past sites when designing new ones with a similar layout, so moving to a framework is a logical step. Thanks for bringing Yahoo’s UI library to my attention, too – it looks incredibly useful. I look forward to cutting out time working out issues like why my div is 2 pixels to the left in IE and having fun getting back to actually designing!
Jon Henshaw
If you use “TextMate”:http://macromates.com/ , you can specify the default content when creating new files types. For example, you can edit the template that creates new XHTML Strict 1.0 documents to already have the structure you prefer (like including YUI CSS links, etc…).
I then use “Snipplr”:http://snipplr.com/ and their “TextMate Bundle”:http://snipplr.com/extras/textmate/ to easily pull in my own code snippets or favorite code snippets. The bundle saves those snippets offline in TextMate, which is useful if I’m coding offline. The combination of TextMate and Snipplr is my framework.
Darren Jones
Good article, this is something that I’ve been thinking about quite a bit recently. Most of it seems like common sense, but then all the best ideas do. I agree with Jon Henshaw above with regard to ‘implementing’ this framework.
I have a few core CSS files that I always start a site with:
The last one will eventually have all the main styles in, but it starts with some basics that I always use (styles for links, setting font size to 62.5% etc) and then I build on this.
Any common code that I often use is saved as snippets for use with the Scribes text editor. For example I have a nice snippet that creates a tabbed navigation bar within a few keystrokes – it makes development much quicker.
Zack Katz
Yes!
František Malina
This si a text grabbed from my guidelines
Site-wide blocks like sidebars, navigations and complex forms included after the content section. My ideal positions of the code blocks in the <body> are as follows:
1. Header — contains logo (image) and concise slogan (text) of the site. Header can also contain few links to the most important navigation sections of the site (2-5 links) and breadcrumb trails. It is important to keep this information first for branding and accessibility. This also tells the search engine which pages are the most important.
2. Content — starts with heading 1 and continue with the copy paragraph text, headings (2, 3”¦), unordered and ordered lists”¦ If the content contains semantic blocks, these should be wrapped in a div. Example: information about one product in a group of products should be enclosed in a
<div>. This<div>can contain heading with the link to the product page, image of the product and paragraph text with the product description. More information about the content and copywriting has been in the copywriting guidelines document.3. Secondary content — if you have one, it is usually the non-site-wide navigation specific for the current section
4. Sidebars — should contain site-wide-navigation and all the site—wide search forms and similar stuff. The ideal structure of the navigation is unordered list
<ul><li>”¦</li></ul>or nested unordered list<ul><li>Section<ul><li>Subsections</li><li>another subsection</li></ul></li></ul>in case you have sub sections. If the sections contain many other sub-sections, you should put this in a separate list to the secondary content. See ““http://css.maxdesign.com.au/listamatic/”:http://css.maxdesign.com.au/listamatic/ to find out how to give your list-based navigation the look you need.5. Footer — contains the most generic information. Footer may contain information about author/owner of the page enclosed in the
<address>tag. The<address>should contain full address, e-mail and telephone number. You may want to add more semantics here using VCARD format. To include an address is espacially important for local business sites to make the page rank for local terms: “Type of the business and name of the location”? (E.g.: Travel agents Swindon, PPC Warrington) and ensure user can easily find contact details. Footer can also contain link to T&C, Site-wide sitemap and copyright/licence information.6. Wrapper – Everything is wrapped in the wrapper to make it easier to create which has its
position:relativeto make the layouts easier withposition:absoluteEvery layout style sheet than looks like:
<br /> *{margin:0;padding:0}<br /> body{}<br /> #w{}<br /> #h{}<br /> #c{}<br /> #s2{}<br /> #s{}<br /> #f{}<br /> .class1{}<br /> .class2{}<br /> ...<br /> #c p{}<br /> #c ul{}<br /> ...<br /> #s ul{}<br /> #s li{}<br /> #s ul ul li{}<br />Colours and backgrounds are often separated in the stylesheet called theme.css
If anyone fancy I’ll write an article about my field tested madular CSS/XHTML strategy.
Mulyadi Oey
This is a good article. Thank you.
My main concern is that how are we going to communicate the existing styles to the other designers for reuse? More often than not, the styles do not get reused simply because they are hard to find. Should we create some sorts of documentations (e.g. screenshots) for every major style?
Stephanie Hobson
This is a great article to get us thinking. I really like the idea of standardizing our approach to CSS.
To your list of 5 basic style sheets I might add one for microformats since there are some basic styles I generally end up applying to them and the classes are 100% predictable.
I worry that class names like “tabs” aren’t semantic. I haven’t played around with it myself (I have a full time day job maintaining one site) but I’m wondering what your thoughts are on starting with a predictable basic XHTML layout that has common semantic class/id names in it like a header area with a nav list in it by default and then grabbing an applying different basic style sheets (or parts of sheets) depending on how you want those formatted.
Aaron Murray
Vox wrote a server-side solution to concatenate all their .js and .css files into one each for the client.
http://www.slideshare.net/miyagawa/how-we-build-vox
Start at slide 47. Not much on the detail side, though. Wouldn’t be very difficult, though.
Aaron Murray
Vox wrote a server-side solution to concatenate all their .js and .css files into one each for the client.
http://www.slideshare.net/miyagawa/how-we-build-vox
Start at slide 47. Not much on the detail side, though. Wouldn’t be very difficult, though.
George Huger
I really enjoyed this article, and immediately wanted a solution for concatenating all my css files. Basically I wish @import had less side effects.
So I wrote one, and made it public for anyone else who wants to use it:
http://www.georgehuger.com/cssAutoLoad
10KB PHP file and 2 lines of .htaccess, and you’re off to the races. Supports caching, basic compression, and even a little debug.
I’d like to hear feedback, as I’m new to this sort of thing. Thanks again for the inspiration.
Cheers,
George
LeMel LeMel
On HTTP connections vs. stylesheet size, what’s wrong with using @import in a CSS 2.0 world? Cascading is supposed to be a core feature—it’s the ‘C’ in CSS after all.
For the framework I built for our developers, there is a basic.css. More advanced stylesheets
import the BASIC.css. Some have multipleimports to other css ‘modules’, for example, TOOL.css imports BASIC and GRID (GRID imports TABLE), while GUIDE.css which doesn’t need GRID only imports BASIC and TABLE.As long as you keep the functionalities simple and nested, developers only see a few choices (TOOL, GUIDE), and the cascade logic takes care of the rest, while giving me the ability to add new modules or styles only where needed without steadily increasing BASIC.
I’m sure some more advanced folks will let me know why this is bad somehow, but it has worked here for a few years in our (admittedly homogenous) environment (an intranet).
Peter Michael
As many others, I really like to keep it minimal. But even at minimal, I tend to use at least three CSS files. Basics, IE fixes and then the rest. I’ve never used a framework and probably never will. Good article tough, many points i’ve not know of. Thanks!
bobro
I know it’s been a while since you’ve written this article, but I wanted to tell you thanks for taking the time to share your experience. We have been getting a lot of requests for larger MVC sites that are very complex from a GUI perspective (not to mention the programming aspect), and we are definitely seeking an optimal approach with our CSS and designs, as we’ve been spending a lot of time looking at each other’s CSS and going, “huh?” and “what the …”.
Your article is just what I was looking for.
jeffsturgis
You said:
Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well.
Actually Google Pagespeed project supplies code that can be used to flatten and minify your css into a single request.