one month agoCSS Systems for writing maintainable CSS
I gave a talk this morning at BarCamp London 5 about CSS Systems, a new term that I am using to define a top-down approach to architecting a site's CSS.
A CSS System is a reusable set of content-oriented markup patterns and associated CSS created to express a site's individual design. It is the end result of a process that emphasizes up-front planning, loose coupling between CSS and markup, pre-empting browser bugs and overall robustness. It also incorporates a shared vocabulary for developers to communicate the intent of the code.
The talk elaborates on this concept, and also describes a number of tricks I use to preempt maintainability issues.
You can view just the slides on SlideShare, but as they might not make sense out of context you can download a PDF of the slides with notes for the complete experience.
Aha! Bedtime reading! Thanks for putting this online so quickly.
Ben Darlow 28th September 2008 23:46
A lot of great stuff here, Nat -- and I ned to read it in more detail to parse it all! But, off the top, I LOVE your definition of frameworks versus libraries (something I've had trouble defining, myself):
"I feel the need to define what I call a framework. For me this is something that alters how you write HTML itself. This is different from a library, which simply provides individually reusable components."
Perfect! And I, too, am very much in favor of libraries, and less so of frameworks (when it comes to CSS, anyway). Good stuff!
Jeff Croft 29th September 2008 00:06
I'm with Jeff on your frameworks vs. libraries definition—nicely done!
Also like that you mention patterns, since I talk about them a lot when presenting on markup, CSS and design. Patterns save time, and make it easier to do the right thing, and do it consistently. I think I'll be pointing to your presentation as a resource during some of my own talks now :)
Dan Rubin 29th September 2008 07:58
Hello there,
very very nice slides.
If I compare your do's and dont's with what I usually do, the main differences are that I use the indented CSS style and do rely on verbose specificity most of the time. The reason I do this is that I am often working in what one might call "unknown terrain". There might be a large number of legacy CSS files being about in the project, or a number of developers might work on the same site and use similar class names by accident. In my experience, highly specific entry points are useful to prevent interference.
Pascal Opitz 29th September 2008 09:19
Great stuff Natalie. I had forgotten about the Web Standards Trifle. :)
Andy Clarke 29th September 2008 09:32
Do you have any URLs where I can see CSS systems in action? I think it's a really good approach to communicating how style sheets work. As a developer I often have to make adjustments, and it would help a lot to work with a system I can understand at a high level.
Frameworks and CSS systems are both solutions to the problem of describing style at a higher level than CSS. I think frameworks are particularly optimised towards computer generated HTML.
Alex Farran 29th September 2008 09:55
Very effective and inspiring slides! Thanks.
Ewan Duthie 29th September 2008 10:01
Very nice presentation. Could you imagine to hold this presentation again at a conference in Basel (Switzerland) on 10th October? It's a bit of a short notice, we had planned to have somebody from Opera there talking about the Web standards curriculum, but due to other talks and the risk of jetlag he had to cancel the presentation. But I believe this would be an excellent substitute. Let me know if you're interested.
Martin Kliehm 29th September 2008 10:05
Some really nice ideas here. We've been developing a system ourselves and have come up with something which is largely similar.
I tried to download the pdf, but there seems to be a problem with the link. It would be great to see your notes and the reasons why you are doing a couple of things slightly differently to us.
David Owens 29th September 2008 10:11
Finally some great slides on CSS markup.
Thx for our inline comments in the slides, quiet usefull to understant bulletpoints.
adactio's pics are also really interesting. You always work like this? I guess it was a major project.
Marin 29th September 2008 10:15
Lovely stuff and thanks for posting this up. Maintainability and portability is not something that has come up in discussions on CSS3 much - which is surprising. We either need a consistent approach (your approach, YUI) or a serious think about how to abstract maintainability from the soup of a large single CSS file (even if it is well organised).
George 29th September 2008 10:21
Excellent presentation, Natalie! rich with tips and some great suggestions. I'm making my own notes as I go through the PDF. Thanks a lot for sharing your methods.
Ben Bodien 29th September 2008 10:30
Thanks for sharing your slides as well as notes - lovely visuals - and great content, making your points very clearly.
thanks again :-)
prisca 29th September 2008 10:46
Great slides Nat! I'd have liked to see the presentation. I like the term of "CSS Systems" and your definition of them. I find I constantly make adjustments to my own CSS library and way of styling and a more systematic and consistent structure is something that I'd like to work on. The one you implement at ClearLeft certainly looks pretty detailed.
I agree with Alex (above) that I'd like to see it in action if you have any links?
Ian 29th September 2008 11:21
Thx for sharing the information with us...
shubhangi Deshmukh 29th September 2008 11:35
Just a heads up in case you maintain your slides. Possible typo on slide 14. "To tight deadlines" should be "Too tight deadlines" I think?
srboisvert 29th September 2008 12:51
This was an inspiring talk at the weekend, finally giving me a way of thinking about creating CSS that wasn't dark magic or random hacks. Thanks for putting it online so promptly!
Echoing a couple of comments about the frameworks vs libraries distinction - I think this is true of both CSS and code frameworks and libraries, and I've always had a measure of mistrust for code frameworks - makes perfect sense that this is true of CSS also.
James Aylett 29th September 2008 13:26
Great stuff! If this was a book, I'd buy it.
Paul Downey 29th September 2008 13:29
Excellent presentation, was the highlight of BarCamp for me, thanks!
georgebrock 29th September 2008 14:46
Thanks all for the comments, to respond to a few:
@ Jeff Croft
Thanks, I felt I needed to define what I understood as frameworks with regards to CSS.
Bearing in mind that a CSS System is a result of a process and is created for a specific site, and that you cannot just re-use a system in its entirity for another site. I agree with you, and I feel that CSS frameworks by my definition actually inhibit the maintainability of a site.
@ Pascal Opitz
Taking on an existing project with legacy code can be incredibly difficult to maintain if it has not been built with a CSS Systems approach to engineering the markup and CSS from the beginning.
In that case, using verbose specificity (or sandboxing) can often be the only way to ensure your changes don't have an adverse effect on the rest of the site.
Firebug is your friend. Another tool I find useful in that case is using the topographic view in the web development toolbar or as a bookmarklet in firefox to see how elements are affecting each other. That way if for example something is pushing out its container you can identify the cause of the problem in IE.
With regards to indentation, I stand by my point on slide 44:
It also does not play nicely with the idea of variations on modules, even in heavily complex sites there will be some inheritance from other sections, and because there is no clear spec for indentation like this, although you may understand how you are implementing your CSS, it can easily become inconsistent.
@ Alex Farran
Unfortunately it seams the majority of work I would be happy showcasing, particularly the larger sites, are under NDA until the backend has been implemented. A few small scale examples I have built however would be this site (my blog), the 2008 dconstruct site and liquidfold.net.
There are also images of some of my planning artifacts on flickr.
@ Martin Kliehm
Thanks, that might be possible, I will check and drop you an email this evening.
@ David Owens
The file is quite large (sorry) you might have to wait a bit for it to download but it should work. If it still doesn't, then drop me a line and I will email you a copy, my address is on my abput page. I would be interested to hear how people are doing things differently.
@ Marin
We do, its a methodology that has come about over time, as you will see from the example links that I posted above this approach works really well on small sites too.
@ George
If you look at the presentation with notes you will be able to see my reasoning behind my dislike of YUI grids / Blueprint etc. (Also see my reply to Jeff above)
I am perfectly happy with the idea of splitting stylesheets (though I dont think that having one stylesheet necessarily makes a soup).
What I don't like is splitting stylesheets based on the nature of the rules, so having separate ones for layout typography and colour are pretty much out in my opinion, have a look at the notes for slide 45.
While splitting out colour can make sense for some sites (e.g. those that support themes) but I'm sure typographers would agree that typography is very strongly linked to layout. For example, changing font size affects dimensions specified in em's, By splitting a rule block for a component it also adds extra mental overhead in deciding which file a particular rule should go in. Keep bearing in mind 'what it is you are styling' think about the higher level of organisation.
I would recommend splitting your stylesheet as I have used groups, including your styles for general elements, followed by a stylesheet for helper styles etc.
@ srboisvert
Thanks for the headsup though it was not a typo, it was a sentance I separated into bullet points :) i.e. "At Clearleft we strive to produce high quality code, to tight deadlines, for handover to external developers".
I'll look at clarifying this if I give this talk again.
@ Paul Downey
Thanks ... one step at a time ;)
Natalie 29th September 2008 17:03
Finally some real-world tips for organizing CSS files. Thank you very much!
leo 29th September 2008 17:15
Thankx for sharing this helpful information. I love playing around with CSS and this is also very helpful for me. I hope it will be for others as well.
Rahul 29th September 2008 18:27
Right. Although, I still think there are some things that can be abstracted to be reused on virtually every site you build, and there's little reason not to do so. Take, for example, resetting browser default styles: at least for me, this is something that is exactly the same on every site I build. I see no reason not to put it in one place and import it into every project, so that in the very, very rare event I make changes to it, I only have to do it in one place (rather than in each project). I guess that just feels more elegant to me than copying and pasting it into each project.
But we definitely agree in general. Although I will probably always abstract a few base-level things into a library I can reuse on most every site, the end goal should always be to have (what you're calling) a system that is designed specifically for the site at hand.
A couple other comments on things that have been brought up here:
Indentation: I like CSS indentation in concept, but I've never been able to make it work in practice, for the exact reasons you suggest, Nat. Good thought, but I'm afraid it just doesn't seem to work for me.
On Blueprint and YUI grids: I really believe there is a way to abstract grids that is a lot less gross than the way Blueprint and YUI do it. The framework we built at the Journal-World did it without requiring you to liter your markup with divs, and it felt a lot less disgusting to me. Olav took that framework, modified it a bit, and turned it into Blueprint. A few releases in, he changed it to require all the divs, which really, really bothers me (in part because my name is sort of attached that project, even if I was never involved with it, and I hate the thought that anyone thinks I would have done it that way!). Even though I think you can do abstracted grids in a much cleaner way, I also really believe the layout for a site should always be hand-crafted for that site, and not forced into some grid that has been pre-created for you. There's a lot of value in the grid systems Blueprint and YUI offer, but that value is not for serious web design and development shops doing top-quality work. Rather, it's for people who need to get stuff done quickly and don't mind if the code is less than 100% perfect. I think it's important to keep in mind that while the code used when building layouts with Blueprint and YUI may not meet my standards (or yours, or Clearleft's), they're still about two million times better than the code most people write. So, that's valuable.
Splitting stylesheets: I think the biggest reason NOT to split stylesheets hasn't been mentioned here: it adds HTTP requests to the page, which isn't great for performance. Beyond that, I think people should split up their stylesheets however they feel makes sense in their head. I totally get your point about resizing type affecting layout, but that ONLY applies if you're using ems for layout, which is something I virtually never do. I think my point is that this, too, really needs to be decided on a site by site basis. How the stylesheets best divide up depends greatly on the project at hand, and even more greatly on the developer(s) involved, as everything makes sense of this stuff differently. By the way, I totally agree that having one stylesheet doesn't mean it's a soup mess! I've seen some very clean, and long, solo stylesheets in my day. :)
I'll say it again: good stuff, Nat! I'm thrilled you're getting people to discuss this stuff without the negativity that seems to ensue whenever I try to discuss it. The bottom line is this: you and I (and others) may not agree on every point here, but in the end, we're both looking to solve the same problems. We're trying to get people thinking about how they organize, store, and maintain their CSS in an effort to make it more efficient (less repeating yourself!), more elegant (better readability!), and more maintainable (less code to change!). How exactly any one person goes about that isn't really as important (to me, anyway), as the fact that people are thinking about it, and working towards it. Whether it's framework, or library, or systems, or just a collection of best practices with no name attached, I hope people start to care about this stuff, because it DOES make a huge difference to your efficiency, especially when you're working in teams.
Jeff Croft 29th September 2008 18:53
I have to agree with you about indentation. Although, for the sake of people who have not yet read your notes, I think that it is important to specify it as "selector based indentation", which is not the same thing as code formatting.
While I was waiting for the download to complete, I read through the comments, and thought to myself, "that is so completely wrong," simply because that wasn't made clear at the outset.
I've been doing web design and development for over 10 years now, and time has shown me that the MOST important things you can do to increase the maintainability of your code, whether it be CSS, HTML, JavaScript, PHP, or whatever, is format your code consistently.
If you are on a team that doesn't yet have a defined style, define one together and put it in writing. If your team has a defined style, stick with it. 2, 3, 4 years later when you need to revisit something, you'll be in a much better position to more quickly and easily find and change what you are looking for. Clean, neatly, consistently formatted code makes maintenance and changes so much easier.
If your code, or the code you where handed is a jumbled mess, it will take much longer to figure out what is what, and where and why.
Also, don't be afraid to use comments, this will also help when you revisit your code later. The small increase in file size is more than made up for in the ability to quickly and easily understand what does what and why.
Some out there may disagree with me on this saying things like, "Well you've just increased your download time by 25ms to 50 ms." Don't be fooled, that is a very small increase in time, remember 'ms' is a milliseond, one 1/1000 of a second.
Michael Risser 29th September 2008 18:58
@ Jeff Croft
I agree entirely. I apologise for not expressing my point well enough. I believe that a CSS system by my definition cannot be reused in its entirety, unless you want two sites to share exactly the same design.
I do the same as you. I start with a blank library of a browser reset and site-wide base typography (based on a library initially developed in-house at Clearleft by Richard Rutter). I build upon this to develop a system for the site.
A CSS system is effectively a framework for a specific site, but I avoided the term "framework" because this is quite a confused term and often conjures up emotive reactions.
I agree completely.
Indeed. I wasn't doubting their value but I do compare them to auto-generated code and other tools for rapid prototyping (like Dreamweaver).
I thought this was mentioned this in the notes, I definitely mentioned it during the presentation. I should probably write this all up more coherently :) I feel though that if stylesheets are to be split up they should be split on the nature of the component, not the type of the rule.
Totally. I've also found that the CSS systems approach fits in really nicely with the changing requirements of agile development practices.
Natalie 29th September 2008 21:06
This is a great sideshow, I'm learning web design/development and hoping to change career in the next year of so, This is the first time I've seen design concepts, ideas and measurements on graph paper. I've always thought about it but never tried, but I'll be doing this from today.
Also the structure of the css and ideas on ie separated style-sheets is a great idea and something I'd like to look into more. (The lego piece is class!)
This is all new to me and sideshows like this one only help me to achieve my goals.
Many thanks,
John McFarlane 29th September 2008 22:00
I probably just missed it. :) Thanks for taking the time to respond!
And for the record, it's quite coherent. God knows I'm never this coherent on my first pass at something!
Jeff Croft 29th September 2008 22:06
What a great presentation! I forwarded it to every front-end developer in the company.
I find it the hardest when working with a lot of contractors & external agencies to make them comply with the guidelines set out. It is hard to police across numerous large sites that are constantly getting small changes. Also having multiple front-end developers on a project seems to make it difficult (especially when you go on holiday & come back only to meet a new person on the team who changed how things are named & organised...). This is an area I definitely have to put some thought in. A document with guidelines & examples doesn't seem to cut it...
Don't forget as well: you are blessed to work with great designers. I seem to be banging my head against the wall again & again when things are made messy, less usable & less accessible just for the sake of some bling/fancy effect, etc... (& I work for a company that is respected for the websites!)
I also agree with the other commenters: your definition of frameworks & library is nice and clear!
Only thing I disagree with: I love single-line css :-) , but I think it's more about preference than anything else. I also never had the problems with SVN that you mentioned.
Thanks again!
Gilles Ruppert 30th September 2008 17:53
Actually, i'm new to CSS thing... still trying to learn more.
IT Freak 30th September 2008 18:15
This is friggen awesome! I've been trying for some time to get a CSS system going for my personal development as well as at work. I've come close but it so quickly falls apart (thanks mainly to our agile development process). Your system has given me lots to think about and will definitely get things stirred up at work! Thanks so much for sharing your ideas!
Darren Wood 30th September 2008 19:54
Great presentation! I've seen both the slides and read the notes. I've some feedback, so I will quote some of your notes.
I agree. But I prefer (ab)using height instead of width. Both works well if, for some reason, you set the width or height in pixels (for a fixed sized box) . But then,
height:100%have worked better for me. My experience is:width: 100%adds up to the horizontal padding, and that can lead to devastating effects., whileheight:100%works flawlessly, and what it's better, it fixes a few rendering issues on IE6.Some years ago, when I read about this method on "Simple clearing of floats" (SitePoint) I was really happy (and wrote about it, as many of you may have felt. I find it odd that there is people still using the "clearfix" method.
When you find this kind of consistency in your structure/markup, it's a sign of a well-thought design. And that's another important point in the process of creating a CSS System, related to the mantra that says the content makes the design, and not the other way around.
A web-oriented (web mentality) graphic designer may not need to know all the CSS quirks (graphic web design != coding html&css), but he may need to think in terms of what can be achieved using POSH and good CSS practices. This medium has its own rules and limitations.
BTW, another mantra to repeat: a webpage/element usually grows/expands vertically. Tell your designer to try to avoid aligning columns vertically at the bottom, to make a perfect (an invisible "frame") square.
Well said, agree. In this era of "web applications", it's hard to think a webpage as a document. That's a reason for me to believe that this era of web-apps/Ajax/fancyness is abusing this medium, ot at least, abusing current HTML capabilities for marking up content.
Although using another stylesheet for IE goes in hand with the "Never use browser hacks" mantra, I prefer to have all IE (well, just IE6/7) styles on the same stylesheet. And then, IE6-specific styles are filtered using the
* htmltrick.A tip: if you are overriding a rule (applied to all browser) on IE6/7 stylesheet, put a comment on that particular rule (on the all browsers stylesheet) that saids something like:
/* rule overrided on ie.css */(or something like that). It will save you something on chasing overriden styles for IE.I agree and that's why I've been avoiding overbloated frameworks. And that's why I've been using Tripoli CSS for a while.
Tripoli seems to be in the middle between a CSS reset and a library, and doesn't get in the middle of your HTML, while at the same time, advocating good practices.
Its tagline is: "A CSS standard for HTML rendering".
Interesting idea. Could it also be a
spanwith atitle="required"? Or some IR technique...? What do you think?Another panacea :)
But then, the question is: if it's a fix for a IE6 CSS bug, why would you put it on the all-browsers CSS? ;)
The answer is: it's easier than creating a rule for each floated elements (probably, many) on your IE6-specific stylesheet.
I do it all the time, but I think this is an exception... a little dirty secret.
Thanks again and sorry for my english.
ps: I've been fighting the last half hour to post this nicely crafted HTML comment here... I think there is some python product (Zope, right?) complaining about my markup. And it was right, I've made some invalid HTML, but really, it was driven my crazy :D. Take a look at Textpattern and Textile" ;)
Julián Landerreche 30th September 2008 22:21
its a bummer your legos dont match the grid paper. seriously, count the bumps.
legomaniac 1st October 2008 06:05
@ Nat:
Yes, Firebug is definitely a very very good friend of mine.
However, noone ensures that it is to the next muppet (as you called em). So I sacrifice reusabilty and choose a more verbose level of specificity to make sure my rules stick.
For the indentation thing:
The way I indent things is by levels of specificity, which doesn't really reflect the exact structure of markup. I use textmate or vim for editing files, so for me this is a valuable visual clue to where significant blocks start and what rules apply to things within those blocks, but hey, that's just me and my (preferred) way of doing things, and I am fully aware that it has its downsides, i.e. SVN flagging up lines as changed when the indentation changes.
Maintaining something like indentation and comments is always something that adds overhead to the actual work. As long as we are aware of the downsides we can make our choices about which trade off we're choosing, I guess.
If I get pulled into a project I ultimately try to integrate with the way people work, may that be indented, camel-cased, underscored, one liners, whatever ...
Did I read something about splitting files and multiple requests somewhere up there?
How about merging the files into one and running YUI compression on them, when the site gets deployed? Works a treat!
Pascal Opitz 1st October 2008 16:34
reading Jeff Croft on browser style resets:
A global reset is something I often consider, but then have to avoid, because the users might be allowed to utilize a rich text editor or something else that spits out unknown markup into the site.
Suddenly you have things that they wanted as lists looking like squished together blocks within the container for their copy, and them frantically calling you up.
So I end up writing specific rules for pretty much every element, or at least only from one entry point on, to not affect the content managed areas.
Any good ways to deal with this?
Pascal Opitz 1st October 2008 16:53
Thanks for sharing this, it was a very interesting read.
Pascal, what I do is use the reset and typography CSS from the Blueprint framework as my starting point on every project.
Tony Geer 2nd October 2008 03:06
When I try to download the .pdf, it says that the file is damaged and can not be repaired. Is there another place to get the .pdf? I would love to see it and read it all. Thank you!
Todd 2nd October 2008 14:50
I've just updated the PDF to be a smaller size - it's 4.9 MB now. Let me know if it still doesn't work for you.
Natalie 2nd October 2008 23:25
Spending time doing a CSS file just for IE6, is a waste of time if you ask me. I think using conditional comments are perfectly acceptable. Seriously who wants to maintain different CSS files for different browsers, if you work on a site that gets millions of pageviews and has tons of different layouts, its a waste of time to bother with seperate CSS files for each browser, other than 1 for the conditional comments for ie6 and maybe one for ie7.
bob 3rd October 2008 17:08
Good stuff, very interesting.
Got to try out that review part :) !
Robin Jakobsson 7th October 2008 08:47
You should think about adding a mp3 of you going through the slideshow (next slide) so i could follow along and not have to read it ;-)
joe public 8th October 2008 02:34
Thank you, Natalie (same name as my daughter - she wants to be a web designer also!). It works and is a very interesting read. Thanks again!
Todd 9th October 2008 09:17
I have to say I agree with pretty much everything in your presentation, and I'm pleased to see we think very similarly... except for one thing... kinda :)
I disagree with the slide about selector based indentation. I use indentation and don't indent relative to the HTML structure, I indent relative to relationships in the CSS regardless of where the elements are in the HTML. I suppose this is looks pretty much the same as your example but with the different way of viewing the method. I find this greatly improves the readability of my CSS and has little effect on the modularity.
Oh and I disagree on one other thing, marking up your CSS to work in cssEdit (all that @group stuff). Of course your CSS is still understandable without it, but a third party app should not define how you write CSS, which it is doing in this example.
Ryan 14th October 2008 10:13
@ bob:
I'm not sure if I made the point clear enough in my presentation, but I agree with you. Two solutions - one for IE and one for everything else - leads to code branching which is unmaintainable in the long run. IE specific styles should be kept to an absolute minimum, and only used when there's no sensible alternative.
@ Ryan:
Pleased to hear you agree with most of my principles. It would be interesting to see an example of your indentation structure.
Natalie 14th October 2008 22:10
Actually today I've been looking at the way I do indentation and I can't quite decide whether it's good or bad, what you say it is or what I think it is.
A few months back I started creating what I called a CSS/HTML framework of files to help kick start web projects (it's nothing like Blueprint). The main idea was to predefine repeat work so I could jump into the meat of a project with a strong foundation. Having read over your presentation I took some time today to really look at how other people may view or use my files.
As I mentioned above your presentation notes have got me questioning some of my techniques... which is great, thanks!
Ryan 14th October 2008 23:43