I agree with everyone who commented that editing multiple stylesheets after the fact is hell. I personally divide my styles into five sections in a single stylesheet: reset, base elements, universal classes, specific IDs/layout, page-specific overrides. Makes overriding a style extremely straight-forward, too, which hasn’t been mentioned yet. Changing styles isn’t always what you need to do.
It’s also worth noting that putting import in your stylesheet, aside from increasing HTTP requests, has an additional downside in IE: IE doesn’t cache any stylesheet that’s two layers out. So if you link to main.css, and then have an import in man.css to screen.css, IE won’t cache screen.css. This won’t matter for most small sites, but in environments where you need to watch your server load and bandwidth it will bite you.
This is good general programming practice (being modular), but creating so many separate style sheets really increases your HTTP request and can significantly damage the load time of you site. From an optimization stand point it’s just more efficient to lump all your CSS into 1 file (same with your javascript, if you can).
A firefox addon was referenced “edit css sidebar” however I cannot seem to find it. The only add on I found has not been updated in quite some time and does not appear to work in ff3. What addon do you use regularly?
Matt Tucker: Look for “Web Developer Toolbar” – it should have what you need and should work in FF3.
As for the article, I tend to agree with everyone else: less CSS files are better for the sake of HTTP requests. We (my company) had a significant difference in load speed and therefore conversion when we grouped our CSS and Javascript stuff.
Copy & paste the code below to embed this comment.
Matthew Goodenough
We have been working tirelessly to separate form and content for years- and yet this article is encouraging the use of CSS that embeds content directly within the stylesheet!
label:after {
content: “:”;
}
From a standards based approach how is this remotely acceptable and when exactly did punctuation become merely a “visual cue”?
I was tremendously disappointed by this article. When Fx2, Fx3, Fx3.1, Opera 9.6, IE6, IE7, IE8, Safari, Chrome, iPhone, and Android are all about to share the stage, I was eager to read about progressive enhancement techniques from the Web-capable handhelds to the judicious use of previously unsafe CSS 2.1 and CSS 3 properties where now applicable.
Boy was I wrong! Instead, a litany of hacks to hide CSS for NN4 and IE5 Mac, praise for conditional comments as if we haven’t already been using them for years, and some seemingly pointless examples of giving different styles to IE7 and IE6 as if for fun. Why? We’re barely two months from 2009.
This article feels like it was written in late 2005 with sloppy mentions of IE7 hastily added prior to submission.
I still look forward to an article on progressive enhancement relating to the current state of the Web.
I’ve tried separating stylesheets into separate files for layout, colors and text and found that it works great on a small scale.
Throw in conditional styles for IE versions and things get a little more complicated. Most of the rules aimed at IE x.x are related to layout so maintenance only becomes an issue on redesigns. But still, it’s something to consider.
Scale things up to the point where thousands of pages call up to 6 files, and suddenly you’re taking a hit in performance and facing increased bandwidth. Even with caching, you’re still going to see a slower load on the visitor’s first visit to the site. And since first impressions are lasting ones, I want to make sure that first page loads as quickly as possible. Maybe just keeping it simple is the best way to go.
Within each row everything is organized consistently. For example the first row is always width then height then margin then padding.
The reason I started doing this was to reduce the amount of lines that one class or id would take up, and more importantly so i could always find what i was looking for in each class or id quicker.
I agree with many of the above. You should limit the number of http-requests.
If I want to split the css in multiple files, I usually create a main.css.php file, which sends itself with a text/css header. This file includes the other css files server side.
This may not be a good idea in every situation, but has been helpful for me on several occasions.
Copy & paste the code below to embed this comment.
Earl Cooley
I’d like a CSS Style editor that databases my style choices and automagically generates CSS files and (x)html linkages (separated and conditionally commented as needed) based on the current state of known browser quirks and failings.
“Dirk”:”:http://www.alistapart.com/comments/progressiveenhancementwithcss?page=2#14” (and others) were completely right in calling me out on the import inside an media crap, it was a last-minute change I made to the article shortly before publication and which I realized—a little too late—was neither valid or supported (and rightly so). I was looking for a way around the media declaration issue with IE and thought I had found it, but only managed to find massive fail. Again, I apologize profusely for not catching it earlier, but I have corrected that now and reverted the article to use my previous method.
Mea culpas out of the way, I’d like to take a moment to address a few other bits and bobs being brought up on the thread:
server requests – yup, this means more server requests which can cause site performance issues, but there are many ways you can reduce that performance hit. CDNs are a good option, but you could also weight the benefits of PE with CSS against your performance needs. Perhaps you don’t need to worry as much about playing a game of “hide the stylesheet” from those special browsers. If that’s true, you should count yourself lucky. Which brings me to…
the point of this article – contrary to what you might think, this isn’t a “check out this nifty trick” piece. In fact it’s not even about trying to convince you to do what I have found works… it’s about getting you to think about how you can apply CSS in a progressively-enhanced way. Thankfully, most browsers in use today have a fairly comparable feature set CSS-wise (or at least they will when IE8 comes out of beta), so PE with CSS isn’t as big a deal as it used to be (since CSS hasn’t gotten an overhaul in quite a few years), but it’s still a good thing to think about, especially since CSS3 is (hopefully) right around the corner.
Anyway, I’m off to bed, but thanks so much for all of your feedback.
Define your three-letter-acronyms please. Thanks for the answer, Aaron, but you could expand your acronyms. It’s late and I’m not able to expand them in my head, hurting your intended clarity:
I was very happy and interested into the first part, now part 2 was for me, like others above a bit of a shock. - I actually cannot and do not want to think about anything before IE6.
I work for social network, so backwards compatibility is absolutely necessary. But we decided to draw a clear line (the bottom is IE 6).
I personally prefer to use 2 to 3 stylesheets (main for screen and print!, IE 6 and if necessary IE7). I used to split stylesheets in colors / backgrounds, typo and layout, but ended up with 1000 lines each, that was not main table.
The idea of using a table of contents is great, and when I will get myself deeper into mobile development (thanx for the links!!) more extra sheets might be interesting.
But I believe the less the better.
Different stylesheets like you describe is not easy to maintain. All that switching between files when changing the properties of an object. I’ve tried it ones. Never again.
I’m in favour of a table of contents at the top and only one well organized stylesheet. Only for cms admin pages and for print I do you use different stylesheets.
Chris Pond—
The ALA comment textarea uses Textile for formatting. See the line just above it for a link to documentation and a sandbox.
The comment preview is a tad limited, it seems.
Matthew Goodenough—
Colons have been stylistic elements and a “visual cue” since their inception in modern typography, and are not part of content. Putting them in CSS is entirely correct and acceptable. The same goes for periods, capitals, semicolons, quotes, dashes, italics-for-emphasis, large size for headers etc.
In this context, an equivalent alternative to the semicolon, as an example, would be a little extra padding on the right and a small background image to indicate the connection between the label and the field.
I agree that the distinction can get a little hard to enforce, because without all the visual cues we put in text, the content would be very hard to read, and thus it’s odd to not lock them inside the text as though they were content. But here we talk about colons on a label; not colons in a sentence, and taking advantage of CSS is recommendable.
Come, now, Mr. Jeffery! Continuing your logic, the spaces between words themselves are merely “visual cues,” not “content.” After all, Mayan, Olmec, Aramaic, Coptic, Hebrew, Classical Greek, and Phoenician were written for centuries without them. Let’s strip these newfangled presentational elements from the true content, wrap every word in its proper span tag, and let the user agents use pseudoclasses to render the visual cues to the wusses who visit our Web pages, if and only if their browsers prove them worthy!
I don’t think you can support all kinds of browsers and devices if you have a common markup for all. But it can be used in conjunction with the XUL i suppose. So that you always have your data in xml format and it will be common item. Then you can seperate the browsers/devices into groups and create different markups for each group. And at last for each group you can apply progressive enhancement.
@Willem Jeffery – I agree with Jon Zuck: colons, periods, capitals, semicolons, quotes and dashes aren’t stylistic elements, they’re punctuation. However, I don’t have a problem with the CSS content example that Aaron’s used, because a label / input pairing isn’t really a sentence, so it’s debatable whether the colon would be considered ‘content’ or not. (You’d also need to be mindful of labels that are actually questions which would need to end with a question mark rather than a colon.)
Re: editing CSS with the webdev edit CSS pane – does anyone else do this? I imagine it’d be a bit of a chore but maybe that’s because I’ve got used to using programs that autocomplete lines when you type a few characters.
It is “interesting”? that this article completely ignores performance and maintainability, and yet these are critical to modern, professional web development.
I respect ALA too much to go into any further detail – instead I do offer an article that would clarify these concerns.
Copy & paste the code below to embed this comment.
Kari Pätilä
@Aaron – Using a CDN to compensate for the additional http requests doesn’t make sense to me. The network does nothing to reduce the amount of requests. It just adds another DNS lookup into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.
However, if you merge the CSS files into a single file that is served compressed (as mentioned on earlier comments) you mitigate the performance issues in one swoop.
Copy & paste the code below to embed this comment.
Greg Burghardt
Having worked on several social networking sites, the shear number of HTTP requests is our biggest enemy. I’ve settled on a modular based approach. Many social networking pages have similar “boxes” of content or modules. We have one common.css file which contains styles used by multiple modules, and then each module gets its own style sheet.
Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.
The average page then loads the common file, probably one or two module files, a common print file, and then IE-only style sheets.
Now if only we could target JavaScript for specific media types…
I really like the idea of fragmenting styles. It’s tough, though, to decide if the fragmentation should be by topic (fonts, colors, etc.) or by DOM location (header, footer, sidebar, etc.); or by media type, as addressed by this article. The problem, though, is that each new fragment would require another HTTP request. Efficient HTTP caching makes this a moot point for successive requests, but a slow first page load may influence whether successive requests are made (maybe the visitor deems the site too slow and hits the back button).
YSlow preaches the reduction of HTTP requests, suggesting that maybe we should have just one CSS and one JS file for the site, and serve it via CDN. This seems to preclude CSS fragmentation… but not really.
Rails developers have the option of using “SASS”:http://lab.hamptoncatlin.com/play/with/sass (packaged with “Haml”:http://haml.hamptoncatlin.com ) to generate Syntactically Awesome Style Sheets. Styles can be managed in fragmented files (as many as you wish), and compiled into one compressed CSS file—and by “compressed” I mean compacted (one line per selector) or compressed (entire stylesheet on one line).
A clever author could use one stylesheet per media type with virtually no repetition (keeping the fragmented files DRY, folowing the Rails Way). Really, the possibilities with SASS are endless: it even supports color math!
Copy & paste the code below to embed this comment.
Richard Fink
First, I think some are overreacting to Gustavson’s casual mention of NN4 and IE5. My own feeling is that if you want to accomodate user agents going that far back, stick to Quirks+HTML3 but let’s give the author points for being thorough and move on… OK?
What I liked about the article was it’s tone with regards to the need to accomodate IE6 and IE7 as a given, as something which simply must be done at this point in time, period. Just a fact of life.
To some this is completely obvious; a no-brainer. But in other forums, I’ve run into designers and developers who I find are, frankly, near-delusional about this. (IMHO) There’s two memes worming their way through the technosphere:
1) An inflated sense of the installed user base for FireFox – to the point where IE is talked about as if it no longer mattered because “it’s days are numbered”.
2) The belief that there is a magic button that can (and will!) be pushed soon whereby all the remaining IE users (poor saps) will suddenly find themselves using FireFox 3, or Opera 9.6 or Safari for Windows.
Now, whether these ideas turn into sites which no longer look good or behave well with IE6 (or even 7) remains to be seen.
But IE6 has an installed user base of, at a very conservative guess, what, a hundred million users?
Their numbers will dwindle but it will still be some years before we can design confidently without taking IE6 into account. IE7, even longer. No matter how hard Microsoft pushes an upgrade to IE8.
And in the meantime, conditional comments or their equivalents will be the order of the day.
Copy & paste the code below to embed this comment.
Sander Aarts
@“Richard Fink”:http://www.alistapart.com/comments/progressiveenhancementwithcss?page=5#49
I don´t think it will take that much longer for IE7 to disappear, than it will take IE6. IE8 installs on the same platforms as IE7 and has the version switch. This makes switching from IE7 to IE8 pretty easy, not like switching from IE6 to IE7. I can even imagine that for that reason IE7 will again have a smaller market share than IE6 in the end. Certainly hope not though.
I agree with a lot of commenters here that splitting all your stylesheets into colour, type and layout is unhelpful. The suggestion that the print styles for any of these three will relate to the screen styles is pretty unimaginative too – on most of my sites, there is very little correlation between type (sans serif for screen, serif for print), colour (may use light-on-dark for screen, not for print – may use background colours on screen, often doesn’t work in print) and layout (print sheet removes most layout styles, and removes some elements completely!).
No, where multiple stylesheets come into their own is when you have a site with a set of generic styles across all pages, but with a different colour scheme for different sections. That is exactly what ALA does! Each edition has a different colour scheme, which keeps all the colours in a separate stylesheet so they don’t clog up the main one.
When CSS can recognise user-defined variables, this may become redundant, or at least less useful, but in the meantime, it’s a very good use for multiple stylesheets.
Copy & paste the code below to embed this comment.
Dave Chapman
I think the article title was a little misleading, I (like others) expected more e.g. bit’s and bobs from CSS3 (and browser extensions) e.g. multiple background images, css gradients, css transforms, @font-face, css tables etc, etc, (with IE 6 as a baseline browser).
Having used third party software that utilises multiple stylesheets I have to agree with most of the comments:
1. It’s a maintenance nightmare… 8+ stylesheets!!
2. It will slow down the initial load of the site
3. A CDN is used to serve content based on the (network) proximity of the user requesting the resource – the fewer the network hops to the server the quicker the response time.
There is an “alternative”:http://blog.niccai.com/post/51688182/maintainable-css-using-ie-specific-css-selectors (better?) way of using conditional comments to target specific versions of IE without having to result to multiple stylesheets.
There are lies, dam lies, and statistics but… I’ve access to the log stats of a (non-technical) public facing website and over the last 12 months there has been 1 visitor using IE5 and none using Netscape 4… I wouldn’t spend anytime designing for those browsers…
This might be worth a look for writing maintainable css “CSS Systems”:http://natbat.net/2008/Sep/28/css-systems/
recent articles have been below par in quality. I think even Sixrevisions and Smashing magazines are getting a lot better. This article really does sounds like it was written in 2005. IE 5.5? Netscape? Which world are we living in? Splitting css into so many files is a maintenance nightmare that I am glad to do without. I use 1 stylesheet and if a page is complicated, I use another style sheet for a specific page when working with sites with more than 30 templates.
I only hope the next articles are of a better standard.
I’m really surprised to read this article in 2008 from somebody as experienced as Aaron. Everybody is trying to reduceHTTP requests these days, and we all know that @import is the worst, slowest way to add more stylesheets. Kids, don’t try this at home — you will hurt the web!
Apart from the maintenance nightmare it’s simply superfluous to create extra stylesheets for print, not to mention handheld styles. Usually my print stylesheets just involve setting a few elements to display:none and fixing a few colors and widths. That can be perfectly done in one stylesheets with the @media print rule:
This all sounds really awesome in theory. We are all about separating content and style, so why not break up the styles into logical units as well?
But in practice I don’t know how good this is…
Has anyone come up with actual metrics on whether it’s better to have everything in one css file (large initial size, but only one http request) versus broken up (small individual sizes, but multiple http requests) in terms of bandwidth, and perhaps page loading? If multiple http requests causes the bigger hit, then in many cases the separation is a weakness.
Also, initially it seems good to break everything up into different chunks of style. Typography, layout, color, etc. But, as has been mentioned this can make maintenance, and especially development, hell. Currently, if I want to change an element, or there is a bug with an element, I can go directly to that element’s style definition and play with all of its properties in one place. Using this method, I would have to jump around between files searching for the right places.
Also, with page loading, what if one stylesheet hangs when its being downloaded. So the user might see a giant red colored eyesore for a while until the next stylesheet jumps in and fixes it. With one stylesheet, it may take a bit longer for the page to completely load, but for the most part each element receives all of its styles at once.
Copy & paste the code below to embed this comment.
Richard Fink
@sander
IE7 ships with Vista. That’s the big problem. Every new computer with Vista = 1 new IE7 user.
If the results of Microsoft’s efforts at pushing out IE7 to IE6 users – as a “critical update”, no less – is any guide, efforts at pushing out IE8 will come nowhere near eradication. We’ll be dealing with IE7 for many years. BTW, Microsoft publishes a schedule of product lifecycles listing when they will drop support (exclusive of security updates) for different products.
IE6 on Windows XP gets shelved in late Spring 2010.
I’m barely learning C++ and Objective C, would you guys have a recomendation for a book to learn about HTML, XHTML, and CSS? I’ve seen too many and I can’t figure out how to separate the good one from the average ones. Thank you guys.
I always have problems getting conditional statements to work, so I actually use a very lightweight snippet of php code to call seperate stylesheets for IE and firefox. Check it out on my website in the header section. http://www.shockforcestudio.com
As much as I hate when it’s time to apple+tab over to IE6 and 7 from firefox and hit refresh, I must admit that the 2 browsers help to point out a lot of problems with my CSS that sometimes FF/Safari etc. “ignore” and “appear” to render correctly anyway. I find that making small adjustments to my CSS to fix IE6 and 7 issues cause no problems in FF/Safari renders and am embarrassingly grateful that my foes (IE6 and 7) pointed those things out to me. Usually, the fixes make sense too. I very rarely even need to make a separate style for IE6 and 7, thanks especially to standards-compliant ways of invoking has-layout and clearing floats. The last site I made has an IE stylesheet for ONE element, the “behavior” element for PNG support in IE. My continuing inspiration is found in the fact that even the most elite CSS designers today are still abusing CSS because it wasn’t intended to do what we’ve made it do at all. Floating for layout? Although necessary for us now, DIVs were intended to stack one on top of the other. So, in exaggeration, we’re all just hacking our way to the coming days of CSS3 table support, but thank you W3C for current CSS 2.1 spec.
Have a look at a “new book from sitepoint titled Everything You Know About CSS is Wrong”:http://www.sitepoint.com/books/csswrong1/ .
In contrast to the parts of this article you’re dissapointed with, you’ll appreciate “the book’s”:http://www.sitepoint.com/books/csswrong1/ drive toward the future in regards to preparing for new CSS and Browsers and what to do about older browsers, rather than discussing support for NN5 and IE older than 6.
“This is a nifty trick for getting IE5/Mac to ignore a stylesheet.”
It may seem nifty but it makes the code brittle and easily broken. It means that everyone who ever works on this code must recognize all the tricks you are using so they don’t break them.
I don’t call that nifty … I call that hard to maintain.
the PHP spits out a condensed result of loading those files in turn (vars.php allows me to define global values such as “$ugly_red=’#faa’” and then use those values throughout my other css files. (parameterised CSS is good – should have been in the spec all along)
When production time comes along, I just load that css url into the browser as is, and copy/paste the result into “site.css” and change the value in the link tag of the template to remove the time spent by PHP producing my css.
Best of both worlds: single http request, minified css code, and I get to work on small, reusable, maintainable and understandale CSS
As a bonus I also get to parameterise my CSS when I want to as well.
The (very basic) ‘compiler’ I use is here – “http://pastebin.com/f4ea23657”:http://pastebin.com/f4ea23657
Its probably bug-ridden, and its VITAL that you don’t put such a script onto a public server (it only gets used on the dev server that lives under my desk and isn’t externally routable …)
In my current position I work on a site that has many dynamic pages. I would find it too timely to maintain the site wide and page specific CSS in this manner (i just prototyped a page to test). This seems as though it is geared for a small / static site.
We load a few different CSS files (I don’t think load times from different CSS files causing multiple requests is a problem), which are usually a global.css, a portal specific CSS file, and then a page specific CSS file. I prefer to have my CSS rules in one place, because this removes the chance that you may have identical mistakes hidden throughout your 2k lines of CSS. Keep it simple, keep it fresh.
Copy & paste the code below to embed this comment.
Nick Conflitti
Sorry, this is kind of an off topic question. I am using the same kind of browser detector the author used in the article. I have gotten it to work in all version of IE but not Mozilla and Firefox. Is there a browser detector I can use for Mozilla and Firefox similar to the one used in the article that doesn’t require any Javascript? Can anyone help?
Copy & paste the code below to embed this comment.
Hayden Hancock
I just wanted to say that I really enjoyed the article as well as the discussion that has followed.
I would like to respond to some of the comments with relation to actually having multiple style sheets. I think a good technique or tip, is to create one style sheet when in development of the site. Only after the CSS design is complete should you break it up. I think this process with help designers better structure their markup and make it not as cumbersome as first thought.
Using a CDN to compensate for the additional HTTP requests doesn’t make sense to me.so i want to apply this on the <href=“http://www.justcrapsdice.com”>craps dice</a> site.The network does nothing to reduce the amount of requests. It just adds another DNS look up into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.I agree with Jens Meiert, performance and maintainability needs more digging.I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.
Using a CDN to compensate for the additional HTTP requests doesn’t make sense to me.so i want to apply this on the <href=“http://www.justcrapsdice.com”>craps dice</a> site.The network does nothing to reduce the amount of requests. It just adds another DNS look up into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.I agree with Jens Meiert, performance and maintainability needs more digging.I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.
70 Reader Comments
Back to the ArticleIan Beck
I agree with everyone who commented that editing multiple stylesheets after the fact is hell. I personally divide my styles into five sections in a single stylesheet: reset, base elements, universal classes, specific IDs/layout, page-specific overrides. Makes overriding a style extremely straight-forward, too, which hasn’t been mentioned yet. Changing styles isn’t always what you need to do.
It’s also worth noting that putting
import in your stylesheet, aside from increasing HTTP requests, has an additional downside in IE: IE doesn’t cache any stylesheet that’s two layers out. So if you link to main.css, and then have animport in man.css to screen.css, IE won’t cache screen.css. This won’t matter for most small sites, but in environments where you need to watch your server load and bandwidth it will bite you.Tim-Wright
This is good general programming practice (being modular), but creating so many separate style sheets really increases your HTTP request and can significantly damage the load time of you site. From an optimization stand point it’s just more efficient to lump all your CSS into 1 file (same with your javascript, if you can).
my2cents
Matt Tucker
A firefox addon was referenced “edit css sidebar” however I cannot seem to find it. The only add on I found has not been updated in quite some time and does not appear to work in ff3. What addon do you use regularly?
Tracy Osborn
Matt Tucker: Look for “Web Developer Toolbar” – it should have what you need and should work in FF3.
As for the article, I tend to agree with everyone else: less CSS files are better for the sake of HTTP requests. We (my company) had a significant difference in load speed and therefore conversion when we grouped our CSS and Javascript stuff.
Matthew Goodenough
We have been working tirelessly to separate form and content for years- and yet this article is encouraging the use of CSS that embeds content directly within the stylesheet!
label:after {
content: “:”;
}
From a standards based approach how is this remotely acceptable and when exactly did punctuation become merely a “visual cue”?
Jon Zuck
I was tremendously disappointed by this article. When Fx2, Fx3, Fx3.1, Opera 9.6, IE6, IE7, IE8, Safari, Chrome, iPhone, and Android are all about to share the stage, I was eager to read about progressive enhancement techniques from the Web-capable handhelds to the judicious use of previously unsafe CSS 2.1 and CSS 3 properties where now applicable.
Boy was I wrong! Instead, a litany of hacks to hide CSS for NN4 and IE5 Mac, praise for conditional comments as if we haven’t already been using them for years, and some seemingly pointless examples of giving different styles to IE7 and IE6 as if for fun. Why? We’re barely two months from 2009.
This article feels like it was written in late 2005 with sloppy mentions of IE7 hastily added prior to submission.
I still look forward to an article on progressive enhancement relating to the current state of the Web.
Michael Wong
I’ve tried separating stylesheets into separate files for layout, colors and text and found that it works great on a small scale.
Throw in conditional styles for IE versions and things get a little more complicated. Most of the rules aimed at IE x.x are related to layout so maintenance only becomes an issue on redesigns. But still, it’s something to consider.
Scale things up to the point where thousands of pages call up to 6 files, and suddenly you’re taking a hit in performance and facing increased bandwidth. Even with caching, you’re still going to see a slower load on the visitor’s first visit to the site. And since first impressions are lasting ones, I want to make sure that first page loads as quickly as possible. Maybe just keeping it simple is the best way to go.
Chris Pond
Great article it’s a larger scale of something I’ve currently been doing.
I work on sites smaller then 1500 + lines so my idea was to organize everything in 3 rows.
- First row being layout
– Second row is text
– Third row is borders backgrounds
See the example below:
#id_name {
width:100px; height:auto; margin:0; padding:0;
color:red; font-size:1.3em; text-align:center;
border:solid 1px green; background:white;
}
Within each row everything is organized consistently. For example the first row is always width then height then margin then padding.
The reason I started doing this was to reduce the amount of lines that one class or id would take up, and more importantly so i could always find what i was looking for in each class or id quicker.
Chris Pond
So the text box didn’t render my example how I expected it do so here it is again. Sorry.
width:100px; height:auto: margin:0 10px; padding:20px 0;
color:red; font-size:1.3em; text-align:center;
border:solid 1px green; background:white;
Chris Pond
Wow, I guess this thing doesn’t like my returns. Last try at it.
width:100px; height:auto: margin:0 10px; padding:20px 0; (——NEWLINE——) color:red; font-size:1.3em; text-align:center; (——————NEWLINE——————) border:solid 1px green; background:white;
Chris Pond
Sorry guys. I’ve successfully made myself look like an idiot.
Bart de Goeij
I agree with many of the above. You should limit the number of http-requests.
If I want to split the css in multiple files, I usually create a main.css.php file, which sends itself with a text/css header. This file includes the other css files server side.
This may not be a good idea in every situation, but has been helpful for me on several occasions.
Earl Cooley
I’d like a CSS Style editor that databases my style choices and automagically generates CSS files and (x)html linkages (separated and conditionally commented as needed) based on the current state of known browser quirks and failings.
Aaron Gustafson
“Dirk”:”:http://www.alistapart.com/comments/progressiveenhancementwithcss?page=2#14” (and others) were completely right in calling me out on the
import inside anmedia crap, it was a last-minute change I made to the article shortly before publication and which I realized—a little too late—was neither valid or supported (and rightly so). I was looking for a way around the media declaration issue with IE and thought I had found it, but only managed to find massive fail. Again, I apologize profusely for not catching it earlier, but I have corrected that now and reverted the article to use my previous method.Mea culpas out of the way, I’d like to take a moment to address a few other bits and bobs being brought up on the thread:
Anyway, I’m off to bed, but thanks so much for all of your feedback.
John Lascurettes
Define your three-letter-acronyms please. Thanks for the answer, Aaron, but you could expand your acronyms. It’s late and I’m not able to expand them in my head, hurting your intended clarity:
Philipp Christoph Taotsu
I was very happy and interested into the first part, now part 2 was for me, like others above a bit of a shock. - I actually cannot and do not want to think about anything before IE6.
I work for social network, so backwards compatibility is absolutely necessary. But we decided to draw a clear line (the bottom is IE 6).
I personally prefer to use 2 to 3 stylesheets (main for screen and print!, IE 6 and if necessary IE7). I used to split stylesheets in colors / backgrounds, typo and layout, but ended up with 1000 lines each, that was not main table.
The idea of using a table of contents is great, and when I will get myself deeper into mobile development (thanx for the links!!) more extra sheets might be interesting.
But I believe the less the better.
Hans Kuiters
Different stylesheets like you describe is not easy to maintain. All that switching between files when changing the properties of an object. I’ve tried it ones. Never again.
I’m in favour of a table of contents at the top and only one well organized stylesheet. Only for cms admin pages and for print I do you use different stylesheets.
Willem Jeffery
Chris Pond—
The ALA comment textarea uses Textile for formatting. See the line just above it for a link to documentation and a sandbox.
The comment preview is a tad limited, it seems.
Matthew Goodenough—
Colons have been stylistic elements and a “visual cue” since their inception in modern typography, and are not part of content. Putting them in CSS is entirely correct and acceptable. The same goes for periods, capitals, semicolons, quotes, dashes, italics-for-emphasis, large size for headers etc.
In this context, an equivalent alternative to the semicolon, as an example, would be a little extra padding on the right and a small background image to indicate the connection between the label and the field.
I agree that the distinction can get a little hard to enforce, because without all the visual cues we put in text, the content would be very hard to read, and thus it’s odd to not lock them inside the text as though they were content. But here we talk about colons on a label; not colons in a sentence, and taking advantage of CSS is recommendable.
Jon Zuck
@William Jeffery
Come, now, Mr. Jeffery! Continuing your logic, the spaces between words themselves are merely “visual cues,” not “content.” After all, Mayan, Olmec, Aramaic, Coptic, Hebrew, Classical Greek, and Phoenician were written for centuries without them. Let’s strip these newfangled presentational elements from the true content, wrap every word in its proper span tag, and let the user agents use pseudoclasses to render the visual cues to the wusses who visit our Web pages, if and only if their browsers prove them worthy!
Jon Zuck
I misspelled your name, Mr Jeffery. My apologies.
Aaron Gustafson
Sorry about that, “John”:/comments/progressiveenhancementwithcss?page=4#35, it was late for me as well ;-) Here you go:
Ahmet KATRANCI
I don’t think you can support all kinds of browsers and devices if you have a common markup for all. But it can be used in conjunction with the XUL i suppose. So that you always have your data in xml format and it will be common item. Then you can seperate the browsers/devices into groups and create different markups for each group. And at last for each group you can apply progressive enhancement.
Ahmet KATRANCI
In the above comment the name of the technology is called XSL, not XUL. I’m sorry for the mistake.
John Faulds
@Willem Jeffery – I agree with Jon Zuck: colons, periods, capitals, semicolons, quotes and dashes aren’t stylistic elements, they’re punctuation. However, I don’t have a problem with the CSS content example that Aaron’s used, because a label / input pairing isn’t really a sentence, so it’s debatable whether the colon would be considered ‘content’ or not. (You’d also need to be mindful of labels that are actually questions which would need to end with a question mark rather than a colon.)
Re: editing CSS with the webdev edit CSS pane – does anyone else do this? I imagine it’d be a bit of a chore but maybe that’s because I’ve got used to using programs that autocomplete lines when you type a few characters.
Jens Meiert
It is “interesting”? that this article completely ignores performance and maintainability, and yet these are critical to modern, professional web development.
I respect ALA too much to go into any further detail – instead I do offer an article that would clarify these concerns.
Kari Pätilä
@Aaron – Using a CDN to compensate for the additional http requests doesn’t make sense to me. The network does nothing to reduce the amount of requests. It just adds another DNS lookup into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.
However, if you merge the CSS files into a single file that is served compressed (as mentioned on earlier comments) you mitigate the performance issues in one swoop.
Greg Burghardt
Having worked on several social networking sites, the shear number of HTTP requests is our biggest enemy. I’ve settled on a modular based approach. Many social networking pages have similar “boxes” of content or modules. We have one common.css file which contains styles used by multiple modules, and then each module gets its own style sheet.
Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.
The average page then loads the common file, probably one or two module files, a common print file, and then IE-only style sheets.
Now if only we could target JavaScript for specific media types…
Tim Gossett
I really like the idea of fragmenting styles. It’s tough, though, to decide if the fragmentation should be by topic (fonts, colors, etc.) or by DOM location (header, footer, sidebar, etc.); or by media type, as addressed by this article. The problem, though, is that each new fragment would require another HTTP request. Efficient HTTP caching makes this a moot point for successive requests, but a slow first page load may influence whether successive requests are made (maybe the visitor deems the site too slow and hits the back button).
YSlow preaches the reduction of HTTP requests, suggesting that maybe we should have just one CSS and one JS file for the site, and serve it via CDN. This seems to preclude CSS fragmentation… but not really.
Rails developers have the option of using “SASS”:http://lab.hamptoncatlin.com/play/with/sass (packaged with “Haml”:http://haml.hamptoncatlin.com ) to generate Syntactically Awesome Style Sheets. Styles can be managed in fragmented files (as many as you wish), and compiled into one compressed CSS file—and by “compressed” I mean compacted (one line per selector) or compressed (entire stylesheet on one line).
A clever author could use one stylesheet per media type with virtually no repetition (keeping the fragmented files DRY, folowing the Rails Way). Really, the possibilities with SASS are endless: it even supports color math!
Richard Fink
First, I think some are overreacting to Gustavson’s casual mention of NN4 and IE5. My own feeling is that if you want to accomodate user agents going that far back, stick to Quirks+HTML3 but let’s give the author points for being thorough and move on… OK?
What I liked about the article was it’s tone with regards to the need to accomodate IE6 and IE7 as a given, as something which simply must be done at this point in time, period. Just a fact of life.
To some this is completely obvious; a no-brainer. But in other forums, I’ve run into designers and developers who I find are, frankly, near-delusional about this. (IMHO) There’s two memes worming their way through the technosphere:
1) An inflated sense of the installed user base for FireFox – to the point where IE is talked about as if it no longer mattered because “it’s days are numbered”.
2) The belief that there is a magic button that can (and will!) be pushed soon whereby all the remaining IE users (poor saps) will suddenly find themselves using FireFox 3, or Opera 9.6 or Safari for Windows.
Now, whether these ideas turn into sites which no longer look good or behave well with IE6 (or even 7) remains to be seen.
But IE6 has an installed user base of, at a very conservative guess, what, a hundred million users?
Their numbers will dwindle but it will still be some years before we can design confidently without taking IE6 into account. IE7, even longer. No matter how hard Microsoft pushes an upgrade to IE8.
And in the meantime, conditional comments or their equivalents will be the order of the day.
Ahmed Bassel Anjoukeh
I agree with Jens Meiert, performance and maintainability needs more digging. Will this fit with 80 million PVs?
Sander Aarts
@“Richard Fink”:http://www.alistapart.com/comments/progressiveenhancementwithcss?page=5#49
I don´t think it will take that much longer for IE7 to disappear, than it will take IE6. IE8 installs on the same platforms as IE7 and has the version switch. This makes switching from IE7 to IE8 pretty easy, not like switching from IE6 to IE7. I can even imagine that for that reason IE7 will again have a smaller market share than IE6 in the end. Certainly hope not though.
Stephen Down
I agree with a lot of commenters here that splitting all your stylesheets into colour, type and layout is unhelpful. The suggestion that the print styles for any of these three will relate to the screen styles is pretty unimaginative too – on most of my sites, there is very little correlation between type (sans serif for screen, serif for print), colour (may use light-on-dark for screen, not for print – may use background colours on screen, often doesn’t work in print) and layout (print sheet removes most layout styles, and removes some elements completely!).
No, where multiple stylesheets come into their own is when you have a site with a set of generic styles across all pages, but with a different colour scheme for different sections. That is exactly what ALA does! Each edition has a different colour scheme, which keeps all the colours in a separate stylesheet so they don’t clog up the main one.
When CSS can recognise user-defined variables, this may become redundant, or at least less useful, but in the meantime, it’s a very good use for multiple stylesheets.
Dave Chapman
I think the article title was a little misleading, I (like others) expected more e.g. bit’s and bobs from CSS3 (and browser extensions) e.g. multiple background images, css gradients, css transforms, @font-face, css tables etc, etc, (with IE 6 as a baseline browser).
Having used third party software that utilises multiple stylesheets I have to agree with most of the comments:
1. It’s a maintenance nightmare… 8+ stylesheets!!
2. It will slow down the initial load of the site
3. A CDN is used to serve content based on the (network) proximity of the user requesting the resource – the fewer the network hops to the server the quicker the response time.
There is an “alternative”:http://blog.niccai.com/post/51688182/maintainable-css-using-ie-specific-css-selectors (better?) way of using conditional comments to target specific versions of IE without having to result to multiple stylesheets.
There are lies, dam lies, and statistics but… I’ve access to the log stats of a (non-technical) public facing website and over the last 12 months there has been 1 visitor using IE5 and none using Netscape 4… I wouldn’t spend anytime designing for those browsers…
This might be worth a look for writing maintainable css “CSS Systems”:http://natbat.net/2008/Sep/28/css-systems/
Just my 2p.
Divya Manian
recent articles have been below par in quality. I think even Sixrevisions and Smashing magazines are getting a lot better. This article really does sounds like it was written in 2005. IE 5.5? Netscape? Which world are we living in? Splitting css into so many files is a maintenance nightmare that I am glad to do without. I use 1 stylesheet and if a page is complicated, I use another style sheet for a specific page when working with sites with more than 30 templates.
I only hope the next articles are of a better standard.
Martin Kliehm
I’m really surprised to read this article in 2008 from somebody as experienced as Aaron. Everybody is trying to reduce HTTP requests these days, and we all know that @import is the worst, slowest way to add more stylesheets. Kids, don’t try this at home — you will hurt the web!
Apart from the maintenance nightmare it’s simply superfluous to create extra stylesheets for print, not to mention handheld styles. Usually my print stylesheets just involve setting a few elements to display:none and fixing a few colors and widths. That can be perfectly done in one stylesheets with the @media print rule:
@media print { #stuff-that-doesnt-get-printed { display: none } }
Michael N
This all sounds really awesome in theory. We are all about separating content and style, so why not break up the styles into logical units as well?
But in practice I don’t know how good this is…
Has anyone come up with actual metrics on whether it’s better to have everything in one css file (large initial size, but only one http request) versus broken up (small individual sizes, but multiple http requests) in terms of bandwidth, and perhaps page loading? If multiple http requests causes the bigger hit, then in many cases the separation is a weakness.
Also, initially it seems good to break everything up into different chunks of style. Typography, layout, color, etc. But, as has been mentioned this can make maintenance, and especially development, hell. Currently, if I want to change an element, or there is a bug with an element, I can go directly to that element’s style definition and play with all of its properties in one place. Using this method, I would have to jump around between files searching for the right places.
Also, with page loading, what if one stylesheet hangs when its being downloaded. So the user might see a giant red colored eyesore for a while until the next stylesheet jumps in and fixes it. With one stylesheet, it may take a bit longer for the page to completely load, but for the most part each element receives all of its styles at once.
Richard Fink
@sander
IE7 ships with Vista. That’s the big problem. Every new computer with Vista = 1 new IE7 user.
If the results of Microsoft’s efforts at pushing out IE7 to IE6 users – as a “critical update”, no less – is any guide, efforts at pushing out IE8 will come nowhere near eradication. We’ll be dealing with IE7 for many years.
BTW, Microsoft publishes a schedule of product lifecycles listing when they will drop support (exclusive of security updates) for different products.
IE6 on Windows XP gets shelved in late Spring 2010.
Luis Menendez
I’m barely learning C++ and Objective C, would you guys have a recomendation for a book to learn about HTML, XHTML, and CSS? I’ve seen too many and I can’t figure out how to separate the good one from the average ones. Thank you guys.
daniel white
I always have problems getting conditional statements to work, so I actually use a very lightweight snippet of php code to call seperate stylesheets for IE and firefox. Check it out on my website in the header section. http://www.shockforcestudio.com
jon thomas
As much as I hate when it’s time to apple+tab over to IE6 and 7 from firefox and hit refresh, I must admit that the 2 browsers help to point out a lot of problems with my CSS that sometimes FF/Safari etc. “ignore” and “appear” to render correctly anyway. I find that making small adjustments to my CSS to fix IE6 and 7 issues cause no problems in FF/Safari renders and am embarrassingly grateful that my foes (IE6 and 7) pointed those things out to me. Usually, the fixes make sense too. I very rarely even need to make a separate style for IE6 and 7, thanks especially to standards-compliant ways of invoking has-layout and clearing floats. The last site I made has an IE stylesheet for ONE element, the “behavior” element for PNG support in IE. My continuing inspiration is found in the fact that even the most elite CSS designers today are still abusing CSS because it wasn’t intended to do what we’ve made it do at all. Floating for layout? Although necessary for us now, DIVs were intended to stack one on top of the other. So, in exaggeration, we’re all just hacking our way to the coming days of CSS3 table support, but thank you W3C for current CSS 2.1 spec.
Have a look at a “new book from sitepoint titled Everything You Know About CSS is Wrong”:http://www.sitepoint.com/books/csswrong1/ .
In contrast to the parts of this article you’re dissapointed with, you’ll appreciate “the book’s”:http://www.sitepoint.com/books/csswrong1/ drive toward the future in regards to preparing for new CSS and Browsers and what to do about older browsers, rather than discussing support for NN5 and IE older than 6.
jon thomas
“I very rarely even need to make a separate style*sheet* for IE6 and 7…”
Robert Shaver
“This is a nifty trick for getting IE5/Mac to ignore a stylesheet.”
It may seem nifty but it makes the code brittle and easily broken. It means that everyone who ever works on this code must recognize all the tricks you are using so they don’t break them.
I don’t call that nifty … I call that hard to maintain.
Richard Cotton
To have the cake and eat it.
(i build sites based on PHP, but similar prospects exist for other methods, such as SASS for ruby…)
Write yourself a simple “css compiler”, let it concatenate (and minify) your many, many css files into one block and return that to the browser.
I now have simply a css link tag with an href like:
css/css_compiler.php?i=vars.php,reset.php,typography.php,grid.php,project.php
the PHP spits out a condensed result of loading those files in turn (vars.php allows me to define global values such as “$ugly_red=’#faa’” and then use those values throughout my other css files. (parameterised CSS is good – should have been in the spec all along)
When production time comes along, I just load that css url into the browser as is, and copy/paste the result into “site.css” and change the value in the link tag of the template to remove the time spent by PHP producing my css.
Best of both worlds: single http request, minified css code, and I get to work on small, reusable, maintainable and understandale CSS
As a bonus I also get to parameterise my CSS when I want to as well.
The (very basic) ‘compiler’ I use is here – “http://pastebin.com/f4ea23657”:http://pastebin.com/f4ea23657
Its probably bug-ridden, and its VITAL that you don’t put such a script onto a public server (it only gets used on the dev server that lives under my desk and isn’t externally routable …)
Bruce Clark
I agree with a lot of posters that this is a bit too much. Here’s my full blog post about the matter: http://tr.im/10u1
Juston Gaughan
In my current position I work on a site that has many dynamic pages. I would find it too timely to maintain the site wide and page specific CSS in this manner (i just prototyped a page to test). This seems as though it is geared for a small / static site.
We load a few different CSS files (I don’t think load times from different CSS files causing multiple requests is a problem), which are usually a global.css, a portal specific CSS file, and then a page specific CSS file. I prefer to have my CSS rules in one place, because this removes the chance that you may have identical mistakes hidden throughout your 2k lines of CSS. Keep it simple, keep it fresh.
Nick Conflitti
Sorry, this is kind of an off topic question. I am using the same kind of browser detector the author used in the article. I have gotten it to work in all version of IE but not Mozilla and Firefox. Is there a browser detector I can use for Mozilla and Firefox similar to the one used in the article that doesn’t require any Javascript? Can anyone help?
Hayden Hancock
I just wanted to say that I really enjoyed the article as well as the discussion that has followed.
I would like to respond to some of the comments with relation to actually having multiple style sheets. I think a good technique or tip, is to create one style sheet when in development of the site. Only after the CSS design is complete should you break it up. I think this process with help designers better structure their markup and make it not as cumbersome as first thought.
craps dice
Using a CDN to compensate for the additional HTTP requests doesn’t make sense to me.so i want to apply this on the <href=“http://www.justcrapsdice.com”>craps dice</a> site.The network does nothing to reduce the amount of requests. It just adds another DNS look up into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.I agree with Jens Meiert, performance and maintainability needs more digging.I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.
craps dice
Using a CDN to compensate for the additional HTTP requests doesn’t make sense to me.so i want to apply this on the <href=“http://www.justcrapsdice.com”>craps dice</a> site.The network does nothing to reduce the amount of requests. It just adds another DNS look up into the mix and adds cost to the project for no reason. If I’m not mistaken, the point of a CDN is to have the files served from a location closer to the client.Say several pages list forum topics and have a comment box (like a profile page). It makes sense to have a comments.css and a forums.css file. This greatly reduces the amount of CSS I need to write and maintain, with the additional benefit that simpler pages do not need all the CSS overhead that more complex pages do.I agree with Jens Meiert, performance and maintainability needs more digging.I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well.
brain.ui
I generally try to optimize my website css using gzip or defalte methods. These methods are for Apache Server versions.
You can simply create “.htaccess” file and modify accordingly. This will speed up your css and website as well when it get loads.