Practical Maintainable CSS

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

more share options
Embed For WordPress.com

Without related presentations

1 comments

Comments 1 - 1 of 1 previous next Post a comment

+ adski 8 months ago
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!

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

http://www.flickr.com/photos/21984953@N00/38992864/

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

http://www.flickr.com/photos/24839392@N00/2396027766/

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

http://www.flickr.com/photos/nebarnix/337062435/

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

http://www.flickr.com/photos/83096974@N00/466881574/

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

http://www.flickr.com/photos/23762528@N04/3000454012/

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

http://www.subtraction.com/2004/12/31/grid-computi

... this needs diagrams ...

http://flickr.com/photos/adactio/1799116343/

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

http://www.flickr.com/photos/7881731@N06/2639919440/

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

http://macrabbit.com/cssedit

... 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!’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’ll be glad to hear that we don’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’ve been working with CSS for a long time, and I’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 ...

http://www.flickr.com/photos/95141439@N00/357358126/

... 8 CSS rules of ...

... finger instead ...

... if you only take away one rule, make sure it’s this one. It’s key to developing the correct mindset.

If you think about pages first, you’ll find yourself duplicating large amounts of CSS code. Every time you need to create a new page you’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’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’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’re doing a flexible layout it’s a lot easier to deal with changing designs if the internal dimensions are set in percentages. Changing the outer container’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 ‘one ruleblock per line’ 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 ‘lime’ 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 natbat.net.

a.k.a. dealing with the inevitable decent in to browser bug hell

http://www.flickr.com/photos/jurvetson/17945646/

I’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’t like IE very much either. ...

http://images.google.com/imgres?imgurl=http://www.thecimmerian.com/wp-content/uploads//2009/02/cthulhu-6.jpg&imgrefurl=http://www.thecimmerian.com/%3Fcat%3D30&usg=__1_3xzSSQ0vRKSiae37BhSy2KKeE=&h=405&w=540&sz=45&hl=en&start=1&um=1&tbnid=vBgWGVpq9eIEiM:&tbnh=99&tbnw=132&prev=/images%3Fq%3Dcthulhu%26um%3D1%26hl%3Den%26client%3Dsafari%26rls%3Den-us%26sa%3DN

... don’t worry, they’re not as scary as they first seem! In case you’re wondering, that’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’s a pretty good chance what you have done is robust and maintainable. ...

18 Favorites

76ers favorited this 3 weeks ago
Tags css
unthinkingly favorited this 3 months ago
willbolton favorited this 3 months ago
Tags css
Iain favorited this 5 months ago
Gaurav M, UX developer at kick ass rock solid company, favorited this 5 months ago
Tags css web
cyrildoussin favorited this 6 months ago
25thhour favorited this 6 months ago
Tags css natbat
Dan Donald, Web developer favorited this 8 months ago
Tags css
André Luís, Web developer favorited this 8 months ago
Tags css
Bi Oliveira favorited this 8 months ago
Tags css
adski favorited this 8 months ago
AndyDavies favorited this 8 months ago
Tags css design
Zak Mensah, e-learning at University of Bristol, favorited this 8 months ago
Tags css clearleft
Garrett Coakley, Web Developer at Torchbox, favorited this 8 months ago
Tags csss process
Lim Chee Aun, Freelance web designer at Home, favorited this 8 months ago
Tags css

Practical Maintainable CSS - Presentation Transcript

Practical, maintainable CSS Natalie Downe, 4th March 2009 Thursday, March 5, 2009
Hello! Thursday, March 5, 2009
High quality code Thursday, March 5, 2009
beautiful and valid markup Thursday, March 5, 2009
semantic markup & class/id names Thursday, March 5, 2009
bulletproof Thursday, March 5, 2009
separate content, presentation & behaviour Thursday, March 5, 2009
for handover Thursday, March 5, 2009
on agency deadlines Thursday, March 5, 2009
Me Input Output I sit in the middle Thursday, March 5, 2009
Designs, Pattern Information Me portfolio architecture & & CSS system conversations I sit in the middle Thursday, March 5, 2009
RateMyArea Thursday, March 5, 2009
UX London Thursday, March 5, 2009
Clearleft Thursday, March 5, 2009
Tourdust Thursday, March 5, 2009
WWF Thursday, March 5, 2009
Designs, Information Me architecture Output & conversations Input Thursday, March 5, 2009
The design Thursday, March 5, 2009
Server-side Designer developers Me Conversations Thursday, March 5, 2009
... with the designer Liquid, elastic or ﬁxed? 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
... 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
Liquid/Elastic/Fixed? Thursday, March 5, 2009
Liquid Thursday, March 5, 2009
Liquid Thursday, March 5, 2009
Elastic Thursday, March 5, 2009
Elastic Thursday, March 5, 2009
Vertigo is healthy on the web Thursday, March 5, 2009
Thursday, March 5, 2009
Planning Thursday, March 5, 2009
Aim: a mental map of how the core markup will ﬁt together Thursday, March 5, 2009
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 conﬁdent estimating time, and talking to the server-side developers Paul sometimes prototypes to prove me wrong! Thursday, March 5, 2009
Page structure and common components Thursday, March 5, 2009
Thursday, March 5, 2009
header Thursday, March 5, 2009
primary content Thursday, March 5, 2009
secondary content Thursday, March 5, 2009
teaser Thursday, March 5, 2009
The grid Thursday, March 5, 2009
Diagrams Thursday, March 5, 2009
Lots of diagrams Thursday, March 5, 2009
Font size calculations Thursday, March 5, 2009
Heading levels Thursday, March 5, 2009
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 redeﬁne them far too often, and you make more work for yourself Thursday, March 5, 2009
Environment Thursday, March 5, 2009
Tools of the trade Subversion with Versions.app Fireworks TextMate ColorSchemer Studio CSSEdit Thursday, March 5, 2009
ColorSchemer Studio Thursday, March 5, 2009
CSSEdit Thursday, March 5, 2009
Firefox + extensions Firebug HTML Validator - http://icanhaz.com/ﬁrefox-validator Operator (for Microformats) YSlow Web development toolbar (for topographic view) Thursday, March 5, 2009
Topographic view Thursday, March 5, 2009
Topographic view Thursday, March 5, 2009
Testing environments Yahoo! Graded Browser Support VMWare Fusion Constantly test in: Firefox Opera Safari Internet Explorer 6 and 7 Thursday, March 5, 2009
8 CSS rules of thumb Thursday, March 5, 2009
8 CSS rules of thumb Thursday, March 5, 2009
8 CSS rules of ﬁnger Thursday, March 5, 2009
1. Think in terms of components, not pages Thursday, March 5, 2009
2. Think about types of thing, not individual things Thursday, March 5, 2009
3. Prefer classes to IDs Thursday, March 5, 2009
4. Create composable classes Thursday, March 5, 2009
5. Use descendent selectors to avoid redundant classes Thursday, March 5, 2009
<div class=\"news\"> <h2 class=\"news-heading\">Weasel wins tug of war</h2> <p>A weasel defeated an aardvark...</p> </div> h2.news-heading { color: weasel; } Thursday, March 5, 2009
<div class=\"news\"> <h2>Weasel wins tug of war</h2> <p>A weasel defeated an aardvark...</p> </div> .news h2 { color: weasel; } Thursday, March 5, 2009
6. Keep your selectors as short as possible Thursday, March 5, 2009
7. Order your CSS rules loosely by speciﬁcity Thursday, March 5, 2009
8. Prefer percentages for internal layout dimensions Thursday, March 5, 2009
Thursday, March 5, 2009
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 speciﬁcity 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
Quality Assurance Thursday, March 5, 2009
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
Internet Explorer Do I recognise it? Double margin ﬂoat 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
Stay strong... Thursday, March 5, 2009
Or pray to the elder gods Thursday, March 5, 2009
Grr... frickin’ IE! Or pray to the elder gods Thursday, March 5, 2009
Code reviews Thursday, March 5, 2009
Designs, Pattern Information Me portfolio architecture & & CSS system conversations Output Thursday, March 5, 2009
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
Example Thursday, March 5, 2009
A CSS system Thursday, March 5, 2009
a CSS system ... involves a top down approach is personalised for an individual site incorporates a pattern portfolio of reusable markup patterns and CSS deﬁnes a shared vocabulary for developers Thursday, March 5, 2009
? nat@natbat.net Thursday, March 5, 2009