Your SlideShare is downloading. ×
Practical Maintainable CSS
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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 …

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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. ...
  • Transcript

    • 1. Practical, maintainable CSS Natalie Downe, 4th March 2009 Thursday, March 5, 2009
    • 2. Hello! Thursday, March 5, 2009
    • 3. High quality code Thursday, March 5, 2009
    • 4. beautiful and valid markup Thursday, March 5, 2009
    • 5. semantic markup & class/id names Thursday, March 5, 2009
    • 6. bulletproof Thursday, March 5, 2009
    • 7. separate content, presentation & behaviour Thursday, March 5, 2009
    • 8. for handover Thursday, March 5, 2009
    • 9. on agency deadlines Thursday, March 5, 2009
    • 10. Me Input Output I sit in the middle Thursday, March 5, 2009
    • 11. Designs, Pattern Information Me portfolio architecture & & CSS system conversations I sit in the middle Thursday, March 5, 2009
    • 12. RateMyArea Thursday, March 5, 2009
    • 13. UX London Thursday, March 5, 2009
    • 14. Clearleft Thursday, March 5, 2009
    • 15. Tourdust Thursday, March 5, 2009
    • 16. WWF Thursday, March 5, 2009
    • 17. Designs, Information Me architecture Output & conversations Input Thursday, March 5, 2009
    • 18. The design Thursday, March 5, 2009
    • 19. Server-side Designer developers Me Conversations Thursday, March 5, 2009
    • 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. ... 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. Liquid/Elastic/Fixed? Thursday, March 5, 2009
    • 23. Liquid Thursday, March 5, 2009
    • 24. Liquid Thursday, March 5, 2009
    • 25. Elastic Thursday, March 5, 2009
    • 26. Elastic Thursday, March 5, 2009
    • 27. Vertigo is healthy on the web Thursday, March 5, 2009
    • 28. Thursday, March 5, 2009
    • 29. Planning Thursday, March 5, 2009
    • 30. Aim: a mental map of how the core markup will fit together Thursday, March 5, 2009
    • 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. Page structure and common components Thursday, March 5, 2009
    • 33. Thursday, March 5, 2009
    • 34. header Thursday, March 5, 2009
    • 35. primary content Thursday, March 5, 2009
    • 36. secondary content Thursday, March 5, 2009
    • 37. teaser Thursday, March 5, 2009
    • 38. The grid Thursday, March 5, 2009
    • 39. Diagrams Thursday, March 5, 2009
    • 40. Lots of diagrams Thursday, March 5, 2009
    • 41. Font size calculations Thursday, March 5, 2009
    • 42. Heading levels Thursday, March 5, 2009
    • 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. Environment Thursday, March 5, 2009
    • 45. Tools of the trade Subversion with Fireworks TextMate ColorSchemer Studio CSSEdit Thursday, March 5, 2009
    • 46. ColorSchemer Studio Thursday, March 5, 2009
    • 47. CSSEdit Thursday, March 5, 2009
    • 48. Firefox + extensions Firebug HTML Validator - Operator (for Microformats) YSlow Web development toolbar (for topographic view) Thursday, March 5, 2009
    • 49. Topographic view Thursday, March 5, 2009
    • 50. Topographic view Thursday, March 5, 2009
    • 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. 8 CSS rules of thumb Thursday, March 5, 2009
    • 53. 8 CSS rules of thumb Thursday, March 5, 2009
    • 54. 8 CSS rules of finger Thursday, March 5, 2009
    • 55. 1. Think in terms of components, not pages Thursday, March 5, 2009
    • 56. 2. Think about types of thing, not individual things Thursday, March 5, 2009
    • 57. 3. Prefer classes to IDs Thursday, March 5, 2009
    • 58. 4. Create composable classes Thursday, March 5, 2009
    • 59. 5. Use descendent selectors to avoid redundant classes Thursday, March 5, 2009
    • 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. <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. 6. Keep your selectors as short as possible Thursday, March 5, 2009
    • 63. 7. Order your CSS rules loosely by specificity Thursday, March 5, 2009
    • 64. 8. Prefer percentages for internal layout dimensions Thursday, March 5, 2009
    • 65. Thursday, March 5, 2009
    • 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. Quality Assurance Thursday, March 5, 2009
    • 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. 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. Stay strong... Thursday, March 5, 2009
    • 71. Or pray to the elder gods Thursday, March 5, 2009
    • 72. Grr... frickin’ IE! Or pray to the elder gods Thursday, March 5, 2009
    • 73. Code reviews Thursday, March 5, 2009
    • 74. Designs, Pattern Information Me portfolio architecture & & CSS system conversations Output Thursday, March 5, 2009
    • 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. Example Thursday, March 5, 2009
    • 77. A CSS system Thursday, March 5, 2009
    • 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. ? Thursday, March 5, 2009