Practical Maintainable CSS


Published on

Natalie Downe from Clearleft specialises in creating high quality client-side code on agency deadlines. In this talk she shares her development process, from planning through to delivery of a full CSS system optimised for maintenance by a client. The talk includes CSS rules of thumb developed over seven years in the field, as well as tips for taming the beast that is Internet Explorer.

1 Comment
  • Thanks Natalie, I'll refer people to this constant, er, consistent, er .. all the time! :-)

    The 40 min Vimeo recording has a nice tempo and the Silverback screencap works really well. Thanks!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Hello!

    I’m a front end engineer, and I work for Clearleft!

    We do information architecture, user experience design, and usability testing

    and as part of all of this, we often provide our clients with the HTML and CSS that implements our designs, and that’s what I focus on.

    At Clearleft, we strive to produce ...
  • ... high quality client-side code,

    which for us means ...
  • ... beautiful and valid markup,

    we delight in finding the perfect element for every context

    we are perfectionists ...
  • ... we use meaningful markup and class names,

    and avoid polluting our code with too many divs or spans

    this keeps things lean, mean and fast loading ...
  • ... Unlike this apple here, we ensure that our sites are “bulletproof”

    This means that the design holds together despite varying content, for example user generated content or anything that is being spat out from a content management system

    Our sites also work when the browser is resized or the user changes their font size ...

  • ... we embrace the trifle of the web,

    Now I don’t actually like trifle very much, but it does make a nice analogy for client-side web development

    we separate our content and behaviour from presentation,

    this means our sites are still accessible even when CSS or JavaScript is disabled ...

    (for a detailed and beautiful description of the ‘trifle of the web’, please see page 6 of Cal Henderson’s “Building Scaleable websites”)

    btw yes I know this is not a photo of a proper trifle.
  • ... we then have to hand over our markup and CSS

    to external developers to integrate with their back-end code

    and for the client to maintain in the long term.

    and we have to do all of this ...

  • ... on agency deadlines,

    this normally works out at about 2 or 3 weeks to build the client-side code for a brand new site ...
  • ... Every presentation needs some boxes and arrows. But don’t be mislead by the diagram, I’m not just a cog in a machine.

    I get to spend all day making things! ...
  • ... I take designs from our very talented design team and turn them into front-end codeTo give you an example of the range of designs I’ve been implementing recently, here are a few screenshots of ones that are not currently under NDA ...
  • ... RateMyArea was the first site I helped with at Clearleft, nearly a year and a half ago now ...
  • ... UX London is a conference we're running in June. This is the first site we've implemented using ideas and a doctype from HTML 5 ...
  • ... as a web design agency, naturally the hardest site to build was our own. This took at least a year of arguments, many many designs and about five iterations of the front-end code! ...
  • ... Tourdust was the first site we built using an agile methodology with an external server-side development team. This made maintainability and implementation flexibility even more important than usual ...
  • ... and this is what I should have been working on when I was writing this talk!

    As a lover of cute pictures of tigers, it’s great to have some content I can get my TEETH in to! ...

    Ho Ho!
  • So what do I need to get started? Well, obviously I need the design...
  • ... Our designers mostly work in Fireworks, so generally I get handed a Fireworks file with the different pages as layer groups. But the design alone isn't enough
  • ... I also need to have some conversations, both with the designer and any server side developers, before I can start planning how I’m going to build the site. ...

  • ... we’ll talk about liquid, elastic and fixed a bit later on.

    What’s the minimum content scenario? By that, I mean what happens when things aren’t there - for example, a news story that normally has an image but sometimes has to display neatly without one, or a listing page that sometimes has no items

    Will there be themed sections? For example, do news pages have a different header or colour scheme than product listings

    How should we deal with text wrapping e.g. in the navigation? This is especially important for tabs and horizontal navigation. Text wrapping around images is another common query.

    Depending on the nature of the design and the budget, we might opt to use progressive enrichment for some design elements. This means that standards compliant browsers are rewarded with little bits of visual flair which shouldn't be missed by unfortunate ludites stuck with IE ...
  • ... conversations I'll need to have with the developer include if a CMS will be used to manage content. In my experience projects with a CMS involve giving up full control over the resulting markup.

    If internationalisation is a requirement, it’s best to avoid using images with text in them as they make translation much harder. Languages such as German can have translations that are much longer than the original English, as such things are more likely to wrap.

    Languages such as Arabic are particularly trick to support, as they require both the text and the design to flow from right to left instead of from left to right. The browser support for this can be a little shaky, so supporting these languages will add quite a bit of time to the estimate.

    How the themes are to be managed is something else to think about, will I be controlling this with a class on the body or does the CSS need to be generated

    All these conversations lead into the doctype decision. I'm not going to enter this minefield of a debate right now (other than to say that given the choice I prefer HTML 4 strict), feel free to grab me about this later ...
  • ... as I mentioned earlier, this is a decision that has to be made right at the start.

    Not everyone browses the web at the default font size, or with a standard sized browser window. Why not make your site look like it was designed with them in mind?

    In CSS it’s possible to define dimensions in terms of a percentage of the overall browser window, or alternatively as a multiple of the size of the font. Either of these techniques can be used to create what’s known as a flexible layout.

    I feel that flexible layouts are a way of breathing life in to a static design, and adapting it to the flexible nature of the web

    Regardless of the decision you make here, it’s important to resize your browser window and increase and decrease your font size during development to see how this affects the page...
  • ... in a liquid design, the layout adjusts based on the browser width. This is achieved by specifying dimensions in percentages ...

  • ... an elastic layout changes as the font size is increased or decreased. This can be done by setting dimensions using ems, a measurement which is tied to the font size.

    The key advantage of elastic is that the number of words on a line stays roughly the same, allowing for the optimum readability length of 75-100 characters per line to remain

    ... I'd you a video for fixed, but you would’t be able to tell it from a screenshot! ...

  • Be afraid of setting heights on anything, especially when it contains text. Text is liable to spill out or overlap other elements on the page if the font size is increased or more text is added.

    Vertigo is healthy on the web ...

  • ... If you want to know more about implementing flexible layouts, I can recommend this book which came out just a couple of months ago ...
  • Just as you wouldn't consider making a house without a proper plan, I like to spend some quality time with pen and paper before writing a single line of code ...
  • By the end of the planning stage I want to feel comfortable with how I am going to tackle the build
  • ... If I come across something in the design that doesn't have an obvious best solution, I like to create a separate HTML prototype.

    This is my way of proving that something is possible to build in a robust manner.

    Quite often I will roll these prototypes in to the final build.

    Sometimes if I tell Paul, our designer that something is not possible he'll prototype it himself to prove otherwise ...
  • ... now, looking at the site as a whole, we need to identify the

    page structure,

    as well as common components....
  • ... for example, identify areas, such as the ...
  • ... header ...
  • ... primary content ...
  • ... secondary content ...
  • ... individual content components such as the teaser on this page

    we'll talk about common components in more detail later, as they are key to creating reusable code ...
  • ... A lot of modern web design is based around a grid.

    it ensures elements are aligned with each other, and gives the site a nice consistent visual feel

    this needs ...
  • ... this needs diagrams ...
  • ... lots of diagrams,

    it basically boils down to proportions, analyse the site as a whole,

    look at content areas and see how they interact with each other and align to the basic grid

  • ... the grid will normally have some dependancy on the base font size, ask your pet designer if you are not sure.

    you will need to make some initial calculations before you come up with the precise proportions

    I’m pretty hopeless at maths so for me this also involves yet more diagrams

    Don’t be too exact though, IE isn’t very good at counting, and will fall victim to rounding errors

  • ... If you figure out your heading levels from the start this will help decisions later on.

    This seems like a subtle point, but properly designed heading levels are an excellent start for coming up with a sensible overall structure for your site ...

  • ... to avoid making more work for yourself, it’s best to identify the typographical hierarchy for the overall site as early as possible ...
  • Next I'm going to share with you some of my favourite tools of the trade ...
  • ... some sort of version control is invaluable, especially when working with a team.

    We use Subversion, with the long awaited and beautiful Mac application Versions.

    Most of our designs are now done in Fireworks, so I have a copy for slicing up images and otherwise interpreting the design.

    TextMate is my editor of choice, and I also use ColourSchemerStudio and CSSEdit ...
  • ... I use ColorSchemer Studio to pick colours off the design - this means I can store colours from the design for future reference, especially useful for theming ...
  • ... CSSEdit is a development tool for the mac, which I absolutely love. It only edits CSS, but it does it so well that I don’t mind having an extra tool.

    Grouping is by far my favourite feature.

    you can see here on the left hand side it has displayed my nested groups which I use as a navigation aid to traverse the CSS on the right

    There are Windows alternatives available; anything with code folding is worth a look ...
  • ... Firefox is my main development browser, mainly because of the extensions. Firebug is absolutely invaluable - if you ever have to touch front-end code and you don’t have this installed, look it up.

    The HTML Validator extension is incredibly hard to track down, since they don’t update the version on the Firefox addons site. It adds a green “tick” at the bottom right of the browser, and is a constant illustration of whether my code is valid.

    Operator is how I test my microformats.

    YSlow is an extension for an extension! It adds a new pane to Firebug highlighting potential performance problems in the front end code.

  • ... topographic view in the Web developer toolbar is useful for exposing the bare bones of your site. Let’s turn it on ...

  • ... here for example you can immediately see that the container on the lower half of the page is not clearing around its two internal floated elements ...
  • We follow our own version of Yahoo!&#x2019;s graded browser support guidelines, which define which browsers should be tested for the full experience, which browsers should at least make the content accessible and which can be safely ignored. You&#x2019;ll be glad to hear that we don&#x2019;t code for Netscape 4 any more!

    I use VMWare Fusion to run different versions of Windows on my Mac, which lets me safely run more than one version of IE at a time.

    As a general rule, I test constantly throughout development in Firefox, Opera, Safari and IE 6 and 7. I double check other browsers such as Camino and Safari on Windows towards teh end of the development cycle.
  • ... I&#x2019;ve been working with CSS for a long time, and I&#x2019;ve attempted to distil some of that knowledge in to some heuristics, or rules of thumb. Ten would be a nicer number since we all have ten fingers, but I have eight - so maybe these should be ...
  • ... 8 CSS rules of ...
  • ... finger instead ...
  • ... if you only take away one rule, make sure it&#x2019;s this one. It&#x2019;s key to developing the correct mindset.

    If you think about pages first, you&#x2019;ll find yourself duplicating large amounts of CSS code. Every time you need to create a new page you&#x2019;ll have to start mostly from scratch.

    Instead, think about the reusable components that make up the design. Create a core set of components that can mixed together to create hundreds of different page combinations ...

  • ... look for opportunities to classify similar content elements together ...
  • ... which leads us nicely to rule 3: prefer CSS class selectors to IDs.

    Rules assigned to a class (or type of thing) are reusable. By definition, ID blocks can only apply to a single element on a page.

    Classes are the only way to build reusable components.
  • ... another advantage of classes is that you can apply more than one class to an element. Just as permutations of components can create many different types of page, permutations of classes that have been designed to be composable can create many different types of component

    for example, one class could define the layout properties of an element while another class applies its theme and colour scheme. This allows for more possible combinations without needing to add more code ...
  • ... you don&#x2019;t need to get carried away and classes to everything though ...
  • ... so here we have a news item, and the h2 has a class of news-heading.

    Say we wanted to set a colour on the heading. Weasel isn't actually a colour in the spec, but Simon insists it should be...

  • ... A more efficient way of achieving the same effect is to take advantage of the context of this h2 ...
  • If your selectors are too long, you are tightly coupling your CSS to your markup

    You can't move things around, because the selector binds the rules to an exact point in the markup hierarchy.

    This reduces its reusability.

    Shorter selectors are also easier to over-ride.
  • If you&#x2019;re keeping your selectors short, it's more important to understand the cascade, in particular the way CSS rules over-ride earlier rules with the same specificity.

    Following a sensible convention also makes it easier to find things and understand how the code works...
  • ... if you&#x2019;re doing a flexible layout it&#x2019;s a lot easier to deal with changing designs if the internal dimensions are set in percentages. Changing the outer container&#x2019;s width will cause everything inside it to re-adjust...
  • ... here's a planning artifact that illustrates internal widths set in percentages.

    It's an elastic site, so the overall width is set in ems.

    Also, I've added a max-width of 100% to make sure that you never end up with a horizontal scrollbar (or crawlbar) even if the user makes their text huge. This is a handy trick for making elastic designs more robust. ...

  • ... for things like font ...
  • ... margins or background.

    I don't. necessarily.

    Longhand can often be preferable, particularly with background.

    firstly it makes debugging in firebug easier, you can see where overrides are effective.

    you will also have similar issues as the &#x2018;one ruleblock per line&#x2019; when it comes to source control. you can tell that a line has changed but its not imediately obvious which part of that line.

    but mainly and this is more noticable with backgrounds ...
  • ... that by using shorthand its easy to override declarations without meaning to.

    For Example if you are using all the sections of the background like we are here, then its easy to see what this is doing,

    but if on an element you have already specified it as ...
  • ... having a delightful lime green background, and you then you want to have a variation of that inherit the lime styles but also have a transparent background image ...
  • ... rofl.gif

    if you specify it using just the background declaration, then this overwrites the lovely lime green colour

    one solution of course is to specify the colour here too, but then &#x2018;lime&#x2019; is in two places, you are not taking advantage of inheritance within declarations,

    and what if you suddenly want to change to pink, now you have to change it in two places, this is not optimal

    also always bear in mind that people editing your code are likely to be copy and pasting from the rest of the file,

    so you have to set a good example with this throughout your code.

    so a better solution would be ...

  • ... use the longhand version, and override with subsequent longhand versions ...

  • So these are my rules of thumb. I'll be making the list of rules available later on
  • a.k.a. dealing with the inevitable decent in to browser bug hell

  • I&#x2019;m giving away the answer to a good interview question here.

    Could it be a hasLayout bug?
  • As Noel Edmonds will apparently tell you in his best selling self help guide, a Positive Mental Attitude is essential in dealing with IE.
  • ... the alternative is to sell your soul to unspeakable demons from alternative dimensions. They don&#x2019;t like IE very much either. ...

  • ... don&#x2019;t worry, they&#x2019;re not as scary as they first seem! In case you&#x2019;re wondering, that&#x2019;s me dressed as a pumpkin.

    code reviews should be an essential part of your development process. If you can explain your CSS to someone else and have them understand it,

    there&#x2019;s a pretty good chance what you have done is robust and maintainable. ...
  • Practical Maintainable CSS

    1. 1. Practical, maintainable CSS Natalie Downe, 4th March 2009 Thursday, March 5, 2009
    2. 2. Hello! Thursday, March 5, 2009
    3. 3. High quality code Thursday, March 5, 2009
    4. 4. beautiful and valid markup Thursday, March 5, 2009
    5. 5. semantic markup & class/id names Thursday, March 5, 2009
    6. 6. bulletproof Thursday, March 5, 2009
    7. 7. separate content, presentation & behaviour Thursday, March 5, 2009
    8. 8. for handover Thursday, March 5, 2009
    9. 9. on agency deadlines Thursday, March 5, 2009
    10. 10. Me Input Output I sit in the middle Thursday, March 5, 2009
    11. 11. Designs, Pattern Information Me portfolio architecture & & CSS system conversations I sit in the middle Thursday, March 5, 2009
    12. 12. RateMyArea Thursday, March 5, 2009
    13. 13. UX London Thursday, March 5, 2009
    14. 14. Clearleft Thursday, March 5, 2009
    15. 15. Tourdust Thursday, March 5, 2009
    16. 16. WWF Thursday, March 5, 2009
    17. 17. Designs, Information Me architecture Output & conversations Input Thursday, March 5, 2009
    18. 18. The design Thursday, March 5, 2009
    19. 19. Server-side Designer developers Me Conversations Thursday, March 5, 2009
    20. 20. ... with the designer Liquid, elastic or fixed? What’s the minimum content scenario? Missing abstracts, images etc. Will there be themed sections? How should we deal with text wrapping e.g. in navigation? Is there room for progressive enrichment on complex issues? Thursday, March 5, 2009
    21. 21. ... with the developers Will a CMS be involved? How much control do I have over the markup? Internationalisation - Arabic etc? RTL? How will themes be implemented? Doctype? Thursday, March 5, 2009
    22. 22. Liquid/Elastic/Fixed? Thursday, March 5, 2009
    23. 23. Liquid Thursday, March 5, 2009
    24. 24. Liquid Thursday, March 5, 2009
    25. 25. Elastic Thursday, March 5, 2009
    26. 26. Elastic Thursday, March 5, 2009
    27. 27. Vertigo is healthy on the web Thursday, March 5, 2009
    28. 28. Thursday, March 5, 2009
    29. 29. Planning Thursday, March 5, 2009
    30. 30. Aim: a mental map of how the core markup will fit together Thursday, March 5, 2009
    31. 31. Prototyping I prototype the missing pieces of the puzzle - the bits I don’t understand yet I’ll browser test these fully If they work, I’ll probably roll them in to the build (and hence save time later) Means I’m more confident estimating time, and talking to the server-side developers Paul sometimes prototypes to prove me wrong! Thursday, March 5, 2009
    32. 32. Page structure and common components Thursday, March 5, 2009
    33. 33. Thursday, March 5, 2009
    34. 34. header Thursday, March 5, 2009
    35. 35. primary content Thursday, March 5, 2009
    36. 36. secondary content Thursday, March 5, 2009
    37. 37. teaser Thursday, March 5, 2009
    38. 38. The grid Thursday, March 5, 2009
    39. 39. Diagrams Thursday, March 5, 2009
    40. 40. Lots of diagrams Thursday, March 5, 2009
    41. 41. Font size calculations Thursday, March 5, 2009
    42. 42. Heading levels Thursday, March 5, 2009
    43. 43. Identify common sizes for each heading level Override these on a case by case basis If you don’t plan this at the start you’ll have to redefine them far too often, and you make more work for yourself Thursday, March 5, 2009
    44. 44. Environment Thursday, March 5, 2009
    45. 45. Tools of the trade Subversion with Fireworks TextMate ColorSchemer Studio CSSEdit Thursday, March 5, 2009
    46. 46. ColorSchemer Studio Thursday, March 5, 2009
    47. 47. CSSEdit Thursday, March 5, 2009
    48. 48. Firefox + extensions Firebug HTML Validator - Operator (for Microformats) YSlow Web development toolbar (for topographic view) Thursday, March 5, 2009
    49. 49. Topographic view Thursday, March 5, 2009
    50. 50. Topographic view Thursday, March 5, 2009
    51. 51. Testing environments Yahoo! Graded Browser Support VMWare Fusion Constantly test in: Firefox Opera Safari Internet Explorer 6 and 7 Thursday, March 5, 2009
    52. 52. 8 CSS rules of thumb Thursday, March 5, 2009
    53. 53. 8 CSS rules of thumb Thursday, March 5, 2009
    54. 54. 8 CSS rules of finger Thursday, March 5, 2009
    55. 55. 1. Think in terms of components, not pages Thursday, March 5, 2009
    56. 56. 2. Think about types of thing, not individual things Thursday, March 5, 2009
    57. 57. 3. Prefer classes to IDs Thursday, March 5, 2009
    58. 58. 4. Create composable classes Thursday, March 5, 2009
    59. 59. 5. Use descendent selectors to avoid redundant classes Thursday, March 5, 2009
    60. 60. <div class=quot;newsquot;> <h2 class=quot;news-headingquot;>Weasel wins tug of war</h2> <p>A weasel defeated an aardvark...</p> </div> { color: weasel; } Thursday, March 5, 2009
    61. 61. <div class=quot;newsquot;> <h2>Weasel wins tug of war</h2> <p>A weasel defeated an aardvark...</p> </div> .news h2 { color: weasel; } Thursday, March 5, 2009
    62. 62. 6. Keep your selectors as short as possible Thursday, March 5, 2009
    63. 63. 7. Order your CSS rules loosely by specificity Thursday, March 5, 2009
    64. 64. 8. Prefer percentages for internal layout dimensions Thursday, March 5, 2009
    65. 65. Thursday, March 5, 2009
    66. 66. Rules of thumb 1. Think in terms of 6. Keep your selectors as short components, not pages as possible 2. Think about types of thing, 7. Order your CSS rules loosely not individual things by specificity 3. Prefer classes to IDs 8. Prefer percentages for internal layout dimensions 4. Create composable classes 5. Use descendent selectors to avoid redundant classes Thursday, March 5, 2009
    67. 67. Quality Assurance Thursday, March 5, 2009
    68. 68. Internet Explorer Avoid the inevitable IE sinking feeling: test constantly throughout development Use conditional comments to include a separate IE stylesheet Avoid hacks Don’t re-engineer everything just for IE - completely forking your solutions is a really bad idea Thursday, March 5, 2009
    69. 69. Internet Explorer Do I recognise it? Double margin float bug, I’m looking at you Validate markup and CSS Apply borders to innermost elements (compare with Firefox - topographical view is useful) hasLayout bug? Apply position:relative starting at the innermost element Search Google / css-discuss Reduce to the simplest possible non-working version Thursday, March 5, 2009
    70. 70. Stay strong... Thursday, March 5, 2009
    71. 71. Or pray to the elder gods Thursday, March 5, 2009
    72. 72. Grr... frickin’ IE! Or pray to the elder gods Thursday, March 5, 2009
    73. 73. Code reviews Thursday, March 5, 2009
    74. 74. Designs, Pattern Information Me portfolio architecture & & CSS system conversations Output Thursday, March 5, 2009
    75. 75. Pattern portfolio Smallest possible number of documents Expresses every component and layout structure Documents how the markup and CSS should be used Illustrates the project’s shared vocabulary Links to current stylesheets A powerful regression testing tool Thursday, March 5, 2009
    76. 76. Example Thursday, March 5, 2009
    77. 77. A CSS system Thursday, March 5, 2009
    78. 78. a CSS system ... involves a top down approach is personalised for an individual site incorporates a pattern portfolio of reusable markup patterns and CSS defines a shared vocabulary for developers Thursday, March 5, 2009
    79. 79. ? Thursday, March 5, 2009