Responsive Web Design, Part 2 (2015)
Testing And Debugging Responsive Web Design
BY TOM MASLEN
I used to be a terrible web developer. I thought I was really good at my job but looking back now I can see that while I was fast at completing tasks, the code I produced was unmaintainable. Despite having a very good knowledge of how browsers worked, I regularly produced buggy code. And after years of regularly working in teams I was still very precious about my own work, and I lacked the intellectual humility to accept better ideas.
Fortunately for me, making websites was easy. Web development used to be simple: four browsers, all running on desktop computers, two kinds of input and one static design to build. I could get away with creating unmaintainable, buggy code because it was simple to debug and fix. Today this is no longer the case because responsive web design has made our jobs so much harder than it used to be.
Wow. Writing that out feels quite therapeutic. Unfortunately, there are no Web Developers Anonymous help groups for me to continue letting all of this out. If this was a help group and I was introducing myself to you, I’d say, “Hi, everyone. My name is Tom Maslen, and I’ve been practicing web development for about 17 years. Recently I’ve started taking responsive web design. It all started in 2011 when I joined the BBC to work on the new responsive version of the BBC News website. Initially, there were too many browsers and devices for me to support, so I came up with a technique called ‘cutting the mustard’ to help me cope. This technique has caught on now and is becoming more widely used throughout the industry. Since joining BBC News four years ago, I’ve dealt with a large responsive codebase on a daily basis. Typical issues have always to do with how developers and designers work together, the maintainability of our codebase, debugging in the massive amount of devices we now support, and working out the best way to test these devices to suppress the amount of bugs that make it to the live site.”
Thanks for sharing, Tom.
I’ve spent a long time building up a way of working that minimizes the pain points that responsive web design now presents us with. I want to go through this with you: to show you how you can build future-friendly CSS structures that will scale up to support large responsive websites, get you to take testing seriously, but not over-complicate your workflow (responsive web design has now made manual testing almost impossible), and finally, how to sanely prioritize and debug problems in all types of devices and browsers.
Despite what my project manager may say, I’m very happy to tell you that I’m no longer a terrible web developer. The journey from terrible to good is actually quite a typical one; maybe there’ll be some parallels with your own career. I’ve structured this chapter into three parts that roughly cover three phases of different attitudes and ways of working I’ve passed through in my career:
1. How you shouldn’t do it: work fast, make stuff up as you go along, test the day before a release, and constantly release bugs and regressions to the live site.
2. Getting better at making, testing and debugging responsive websites: get burnt by being too pragmatic, get taken under the wing of a wiser developer, be introduced to testing and become a dogmatic follower of the practice, realize the importance of writing maintainable code and start to improve oneself.
3. Expertly applying testing to your development workflow: get burnt by being too dogmatic, decide what works for me, and learn how to write tests correctly and define an optimal workflow.
Phase 1: How You Shouldn’t Do It
Before the iPhone, Chrome, preprocessors, code linting and Sublime Text, my web development setup was quite simple: Microsoft Notepad and Firefox. It seems almost impossible now to think that I was able to create entire websites with such a simple setup, as well as fix and debug CSS rendering and JavaScript syntax errors using only window.alert and my own custom debug tool. Before web browsers had internal dev tooling, we’d fix layout issues by adding debug CSS like this:
td {
border: 1px solid green;
padding: 10px;
}
div {
border: 1px solid red;
margin: 10px;
padding: 10px;
}
h1,h2,h3,h4,p {
border: 1px solid blue;
margin: 10px;
padding: 10px;
}
This simple piece of CSS would help me to find typical CSS rendering issues like unclosed tags, and the double margin bug1 and the peek-a-boo bug2 in older versions of Internet Explorer.
I’d then have to go into the CSS to find the offending selectors or properties and work out where to apply a fix. There was never really any planning put into CSS; typically one CSS file would be used for an entire site. The CSS file would often be over 1,000 lines long. If there were more than one of you working on the single CSS file, then it would quickly become a mess of contrasting styles with no obvious order.
The main issue with CSS is that every selector, no matter where in the file it is located, has the potential to globally apply any CSS property. To combat this I used to use a very obvious selector style:
body div#header { /* ... */ }
body div#header h1 { /* ... */ }
body div#header p#strapline { /* ... */ }
Yes, I was THAT guy. The selectors here are way too verbose, but they helped me to maintain the CSS: it made the order of selectors obvious, created regions for you when you wanted to add a new selector, and implied an order of styling (important when trying to follow the cascade).
Unfortunately, below all of my perfectly structured CSS would be quick fixes, patches to bugs and additional new styling added by other developers or myself when I was in a hurry. Over a long enough period of time the CSS would become ordered chronologically, the latest changes would be at the bottom of the file. Monkey-patching specific browsers with extra CSS files loaded only for them would exacerbate this anti-pattern. Trying to work out the cascade by a series of selectors that are constantly overriding each other and then being overridden themselves by an additional CSS file was very hard.
There was no care or thought put into the maintainability of the codebase. All of the value was placed into how fast I could complete tasks. Web development was different ten years ago than it is today. Back then, we had four web browsers (IE6, IE7, Firefox, and Safari) with rendering engines that were very different from each other. It took a lot of efforts to get a webpage looking the same and for the JavaScript to work across all of the browsers we supported. Today, most browsers are very standards-compatible (go pay some respect to the devs who worked on WaSP3): you can write CSS and JavaScript and expect it to more or less behave the same in every browser. The challenge today is with responsive web design: we need to create interfaces flexible enough to fit into any viewport size and aspect ratio.
Testing was even more chaotic. For most of my professional life, I’ve done most of my own testing. Before responsive web design, I’d develop a website on a PC using Chrome (or Firefox before Chrome was born). When the page was at a certain stage or even finished I’d check it in the following browsers in this order:
•Firefox
•IE8
•IE7
•IE6
•Safari
•Opera
Then I’d go over to a Mac in the corner of the office and check Safari, Firefox, and Opera again. It was common for developers in my team to test each other’s work or for the project manager to test for us. We’d do this testing a few days before we were due to release — it would often be a tense and stressful period where somebody else would be going through my work, pointing out where I’d made mistakes.
Some sites were complex JavaScript applications, holiday booking sites or warehouse applications. Making changes to these codebases was not simple and once the code was released we’d find that we had broken parts of the functionality we hadn’t touched, or that what we made didn’t work in certain circumstances; or, even more typically, that the JavaScript threw an error in IE6. I’d always refer to these as “bugs” when really what I meant was “mistakes in my code.”
It took a long time for me to work out that my blasé attitude toward testing was responsible for all the quality issues we had. “It works on my computer” became a cliché in our industry, and I was one of the biggest sinners for repeating this.
I used to be very precious. I wasn’t a good developer until about five years ago. I didn’t like other developers telling me what to do or testing my code. The one thing I hated more than anything — and this sounds crazy — was releasing code. I would get physically nauseated as a release date came closer. And when we did release, I wanted to run away. Looking back, I think it’s because I knew there would be issues; that once the thing I had been carefully crafting in my personal office space was exposed to the world, people would find problems with my work and I’d be open to criticism.
I don’t know if this fear of releasing is common, but I do recognize preciousness in other developers. It’s a trait I always try to expel from members of my team. An important part of being a good developer is acknowledging that you don’t always get things right, and you should be open to other developer’s opinions. I take inspiration from Brad Frost in this respect, who once said: “It’s not a criticism, they’re helping me to make my website even better!” This expresses an incredible amount of intellectual humility. We should all adopt the same outlook.
We should see testing in the same way. It’s not there to catch you out or to prove you’re not good at your job. Because responsive web design has made front-end development harder to practice, our understanding of JavaScript, browsers, devices and CSS now has to be of a very high standard. This mental model of how everything works together is very hard to keep track of, and testing can help you. To define what things should do, how they do it, and then make sure no regressions appear.
Knowing when to apply testing and how to do it hasn’t been a typical part of a web developer’s skill set. It’s time for this to change.