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.
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
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
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
51. Testing environments
Yahoo! Graded Browser Support
VMWare Fusion
Constantly test in:
Firefox
Opera
Safari
Internet Explorer 6 and 7
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
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
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
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
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 ...
<ACTIVATE>
... 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. ...