Web Standards Group - WSG

Home - WSG interviews

Ten questions for Richard Rutter


Richard Rutter

Richard Rutter is a web site producer living in Brighton and working in London for Multimap. He also runs his own weblog where he shares his personal perspectives on Web development and design, accessibility, usability and information architecture.

[1] Russ: Your blog is a very successful 3 column liquid layout. Even in an extremely wide browser window content seems comfortably readable. How was this achieved?

Richard: I'm a big believer in liquid layouts. I believe liquid layout is more appropriate to a Web where known variants include screen resolution and window size. Those designing for the Web as a medium know their designs must work for any (reasonable) text size so why not any window width? I would hazard a guess that more visitors would know how to change window size than text size.

One of the problems cited against liquid designs is that lines of text can become unreadably long. I counter this in my blog by putting plenty of leading in the text (typographer's terminology for setting line-height to 1.5em). Spacing apart lines of text in this manner helps readers keep track of which line they are reading, and which to read next.

More important to the text layout is a technique I call concertina padding. Each of the three columns on my blog has a width set as a percentage of the window width. All horizontal margin or padding is also set as a percentage width, so as the window is enlarged the padding increases thus keeping the lines of text shorter than they would otherwise be and giving them more room to breathe. Similarly as the window is shrunk, the padding decreases, making giving more room for the text. I visualise the browser window attached to a concertina as it is stretched and squashed with every single horizontal dimension scaling accordingly.

[2] Russ: You have written about how images can be scaled within liquid layouts using overflow:hidden and maxwidth. Could you explain your preferred method?

Richard: Probably the biggest issue facing liquid layouts is how to contain and display fixed width elements such as images and flash movies. Inherently with a liquid layout one never knows the width of a column which inevitably leads to situations where an image is wider than its container and breaks the layout.

There are two approaches to address the issue: automatically shrink the image to fit the narrow column or mask the bit of the image that is too wide for the column. Masking using overflow:hidden works well for panoramic images, alternatively the image can be set as a background if it is little more than decoration. In all other situations, my preferred technique is to set the image width to 100%, which will shrink (or expand) the image to its container, and set a max-width at the true image size to prevent it expanding. Of course max-width doesn't work in IE/Win so you can either accept the image being expanded or apply other max-width techniques such as Dean Edwards's IE7.

[3] Russ: Around 12 months ago you did some research into access keys. Do you think they are relevant and how would you implement them on a site?

Richard: I still use accesskeys for the global navigation on my site, but wouldn't use them as a matter of course. In theory they are a good idea, particularly for their original purpose which was to replicate the behaviour of OS dialog boxes and speed up form filling. One of the hurdles that facing accesskeys is that they require the same keystokes as assistance software such as JAWS, leaving only the numbers available for general use. In the post you mention, I tried to ascertain whether there is an adopted standard set of accesskeys for global navigation and the answer was not really - another problem. But most importantly browsers provide no visual support for accesskeys, so we are forced to code in our own, such as underlines. This in itself causes problems, as highlighted recently on the WSG list, as some assistance software will read something like <span>S</span>earch as S-earch.

All-in-all accesskeys could be used successfully in controlled environments such as Intranets, but their usefulness on the public Web is sadly limited.

[4] Russ: You define your dropdown menus as 'accessible dropdowns'. What is it that makes them accessible?

Richard: The menu works even if style sheets and/or JavaScript are missing. In a recent DigitalWeb article, Peter-Paul Koch wrote about the behaviour layer concept. We already know about the content & structure layer: HTML, and the presentation layer: CSS. The behaviour layer is all your JavaScript (which incidentally should be kept as separate from your content as your CSS file, including all the onclick and onload event handlers).

The content layer should always 'work' with the presentation layer missing, the behaviour layer missing, or both. We often assume that the presentation and behaviour layers are either both missing or both present and this can cause problems. It's a false assumption that CSS and JavaScript hold hands and go everywhere together.

My dropdown menus avoid this problem by using two style sheets. The first style sheet is called by the HTML to make the menu reasonably pretty as a set of horizontal navigation. A second style sheet is called by the JavaScript to render the menu as a hidden drop down. This way we can satisfy all the criteria:

No styles or JavaScript: the menu is an unformatted list. Both styles and JavaScript: the menu is a dropdown. Styles but no JavaScript: users see a horizontal menu. JavaScript but no styles (perhaps a user style sheet is overriding): the menu is hidden and revealed as scripted.

It's also worth nothing that the dropdown is activated using an onclick event handler. According to WAI guidelines this is a failure as onclick implies a mouse must be used; the reality is that the dropdown menu can be operated entirely with a keyboard just by using the tab and return keys.

[5] Russ: You have recently written about text-sizing using ems. What are the advantages and disadvantages with this method?

Richard: In an ideal world we'd all be sizing text in pixels, but if we want IE/Win users to be able to change their text size - which we do - then we need to size text using a relative unit such as keywords, percentages or ems. I find that using ems gives me more precise control of text size than do keywords and with a little practice ems are not much harder than using pixels.

[6] Russ: I have heard rumours that you have just launched a new-look Multimap. The obvious question - is it built using web standards?

Richard: Yes it is, but to be fair it used Web standards beforehand in as much as it validated. We'd got as far as removing all the font tags but the site was still chock full of nested tables and the usual non-semantic mark-up that you would expect to be inherited from a few years ago. We rebuilt the site using meaningful mark-up for two big reasons: ease of maintenance and bandwidth reduction.

The templates used throughout Multimap.com are constructed from heaps of server-side includes. Making changes to the site was a tricky business as any given include might contain one table inside part of another table. Now all the includes are really simple: most just have a div with a proper heading and a list. We're already noticing the increase in speed with which we can make changes. The move to meaningful mark-up has eased this surprisingly stressful part of the job.

As for bandwidth, roughly speaking Multimap.com serves 4 million pages a day. On average, the HTML of the old site weighed in at 65kb per page. The new site pages are half that at 35Kb. That's a saving of 40,000 Gb of bandwidth per year! I'll leave you to translate that into money, but I can tell you the move to Web standards paid for itself within a month.

[7] Russ: It is a very complex layout, yet still full CSS. How did you go about building it?

Richard: The incumbent design is so rigid I thought I'd have to go for a hybrid build with a single table for the main layout and CSS for the remaining presentation. With that in mind, I didn't want to waste days struggling with an all CSS solution to the layout so I gave myself just a morning to find one. I came across some brilliant 3-column layouts which had the added bonus of allowing me to code the middle column straight after the header (thereby ensuring the H1 and the map appear early to Google and non-styled renderings). I will admit to some surprise that, within two hours, I had the basic layout of header, three columns and footer, centred and working across my browser suite.

After that I printed out screen shots of all the different kinds of pages across the entire site (home page, map pages, driving directions, local information, etc.) and picked out all the common structures. From this I worked out a mark-up strategy for each chunk of content, annotating each printout by hand to identify where I would use divs with a given class, headings, unordered lists, tables and so on. Because I planned this site-wide in advance I could reduce the number of classes and ids used and much increase the visual consistency from screen to screen.

In case you're interested I develop primarily in Firefox. Its excellent rendering engine and tools such as the DOM inspector, the Web Developer toolbar and view background image context menu, make Firefox by far the best browser for development. As I get it working in Firefox, I test on Safari and the IE6/Win. I always leave IE5 testing to a later stage.

[8] Russ: Were there any major obstacles you faced when building it?

Richard: Netscape 7 proved to be the biggest pain; one of Multimap's directors browses with Netscape 7 on a Mac so there was no getting away with any discrepancies on that particular platform. Netscape 7 is built on the Mozilla 1.4 branch which has quite a few rendering bugs long since fixed, so it was actually more tricky getting that to behave than Internet Explorer which at least is well documented bug-wise.

I would like to mention that at no point was management buy-in an obstacle to moving to Web standards; the opportunity was there and the benefits of moving to Web standards were so clear the go-ahead was never an issue.

[9] Russ: Did you have to use any CSS hacks?

Richard: One: I used the Blue Robot method of centering a fixed width box. It's not really a hack though, more an addition of style rules for IE/Win (but interpreted by all).

[10] Russ: The big question everyone seems to be asking at the moment - did it take you longer to develop this site using web standards than if you had built it using traditional methods?

Richard: The development process was definitely quicker using Web standards, in fact the idea of rebuilding Multimap.com with nested tables fills me with horror! I had the common templates built in two days, with a further day of tweaking to fix some minor display issues here and there. After that it was just a case of rebuilding the remaining bits of the site in the same mold, a job made easy because of the simple, meaningful mark-up used throughout.

Russ: Thank you for the interview!
Richard: You're welcome Russ. It was tough but fun!

Copyright © Web Standards Group 2012