Stop solving problems you don't yet have

We’re in a really exciting time for front-end web development. Our modern browsers are excellent in terms of their standard support for CSS, and new features are becoming usable far more rapidly than I can ever remember.

This situation is exactly what we asked for in the early days of the Web Standards movement. That browsers support standard features according to the spec, so that developers could build their site using a single browser and be confident that it would then work in the other browsers. Vendor prefixes aside (and I personally believe they are a sane solution to the problem of implementing early stage CSS) that is where we are now. I do most development in Firefox on my Linux desktop and it just works in the other modern browsers and platforms that I test in. Even something that might be considered complex – such as a large-scale responsive design – works pretty consistently across not only desktop browsers but mobile ones too.

However, despite us entering a seemingly golden age of browser consistency, what I am seeing is an increasing reliance on a whole slew of polyfills, CSS frameworks and boilerplate starting points. I am concerned that these things are being promoted as something everyone should include from the outset, rather than being a toolkit you draw on to deal with problems once they have arisen.

Here is my “HTML5 boilerplate”

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title></title>
</head>
<body>
</body>
</html>

That’s it. For at the start of a project I don’t necessarily know what problems I am going to encounter and how I might deal with them. Adding a bunch of polyfill JavaScript at the start doesn’t help. Firstly, I might not need it, however if I have been developing with it there from the start how do I know if there is a better way to do things that negate the requirement for it? Secondly, it might actually cause me a problem – is that issue I am seeing a browser bug, or a problem with the polyfill? Thirdly, if I am adding a lot of JavaScript right from the start I am very likely to end up with bits of my layout needlessly requiring JavaScript to work.

Take the Greenbelt website I wrote about last week. I was working alongside the designer when developing the site, I didn’t know at the start exactly how we would solve many of the problems inherent in such a large, responsive site. So I developed the site for modern browsers, working in Firefox, with a mobile first approach. The only thought I put in for older browsers during the entire front-end development was to make a note of any CSS3 Selectors that I knew were unsupported in IE8 and below. Once we had the site developed and snagged in modern browsers on desktop and mobile, I moved on to look at IE8, 7 and 6.

Problem 1: IE8 and below have no support for media queries

At first view, IE8 was showing the mobile version of the site as it did not load in the other stylesheets. Here I could choose to use respond.js to enable support for media queries (but create a reliance on JavaScript) or include a stylesheet for IE8 that fixed the width. I chose the latter option. I also used this stylesheet to fix up a few small CSS issues that I spotted in IE8.

Problem 2: IE8 and below had no support for certain CSS3 selectors

Some of my layout looked a bit wonky due to my use of CSS3 selectors. I do love my CSS3 selectors. I knew this would be an issue and again I had a choice. I could use a polyfill such as Selectivizr or I could polyfill them myself with jQuery. As we were already using jQuery on the site and I knew exactly which selectors were an issue I chose to just add a function into our global UI file to polyfill these myself. If the site had been littered with these issues then I might have chosen to just use Selectivizr – again, by waiting until I could see the problem I was in the best place to make a decision.

Problem 3: IE6 and 7 … what are you doing?

With the IE8 stylesheet loaded for IE8 and below, the layout actually held up reasonably well in older Internet Explorer browsers. There were of course the usual crazy layout issues which were mainly solved by getting the element concerned to have layout, and a few rounding issues. However I was surprised at how well the layout worked considering that everything bar a few items was still sized using percentages – my IE8 and below stylesheet having fixed the width of the main container.

This large and complex site, which had been over 4 months in development, was tidied up in old browsers in around 1 day of work, mainly by way of CSS added via our old friend the conditional comment.

Don’t solve problems that you don’t have

Build for modern browsers. Test your work in those and make sure the experience for an up to date browsers is as you want it. Then look at the problems you have, alongside your policy in terms of what you are delivering to older browsers, and see what you need to fix those issues.

There is some amazing work out there in terms of polyfills, frameworks and libraries. However you don’t have to use them, and in many cases won’t need to use them. So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.

If you are an experienced developer be very careful about suggesting that a whole slew of things are required as a solid base for any given project. Depending on the sort of projects you work on, it may well be that you do need all of this stuff and make use of it well. However, it’s a confusing world of options out there to the beginner and learning the basics of HTML and CSS development for modern browsers, then solving the issues that come up, is still the best grounding for any new developer.

Comments

Sophie S-K: 21 Mar 2012 at 12:57:46

This is exactly how I work, too! Nice to see that there’s someone out there who feels the same way – it seems too many people these days are insisting on “experimenting” with their clients’ websites, and that’s just not right.

“Experimenting” may, for the record, be the wrong word, but the point stands :)

Jamie Knight: 21 Mar 2012 at 12:59:47

Could not a agree more! Well Said!

J&L

Ronni Egeriis: 21 Mar 2012 at 13:04:47

Your meta tag is invalid HTML. Strip the last slash.

Robert: 21 Mar 2012 at 13:10:13

This is a really good shout. I used to do some very lean code but have recently been chucking some sort of boilerplate or bootstrap type thing at a project in the beginning. Some of it I know is useful like HTML5 enabling scripts but I could live without a lot of what’s provided. It’s laziness on my part.

The one thing where it can be useful is getting past the ‘blank page’ when you don’t always know where to start but that’s not a problem on a well defined project.

Rachel: 21 Mar 2012 at 13:11:57

@Ronni no it isn’t. It is valid HTML5 coded using XHTML style elements as that is my personal preference.

Alastair Campbell: 21 Mar 2012 at 13:13:08

I agree, just a point in defence of (for example) HTML5 boilerplate: As someone not doing regular development, having a set of possible solutions and best practices was very handy.

Last time I started a new set of templates, I started with HTML5 Boilerplate, saved a new HTML file, cut everything out, and then put back the things I needed as I went along.

It was a useful learning experience, rather than my starting point.

Jeremy Keith: 21 Mar 2012 at 13:48:20

Yes, yes, yes!

I am increasingly seeing multiple conditionally-commented html tags at the start of HTML documents and script elements pointing to jQuery on projects that, when I ask “why?”, the answer is often a shrug and “just in case.”

I completely agree that you should start with the real minimum and only add polyfills and libraries as and when required.

Andy Davies: 21 Mar 2012 at 14:23:12

The multiple conditionally-commented html tags are a product of things like HTML5 Boilerplate and what-not aren’t they – people pick the framework without necessarily understanding why they are there…

Paul Cripps: 21 Mar 2012 at 14:24:54

+1 here, great Article Rachel…

This is actually quite spooky as we’ve been having very similar conversations over @ninefour. We always try to “Keep It Simple Stupid”.

I think its far too easy to throw pollyfils, CSS and javascript fixes and frameworks at sites when the majority of the time you’ll neve use it.

We’ve also worked on a few sites recently, where other developers had “chucked everything” at the site and the client was finding it took for ever to load. In some cases we’d managed to get the page load reduced by 90%.

Karolina Szczur: 21 Mar 2012 at 14:38:49

Couldn’t agree more. This is really sad that developers tend to reach out for various libraries and boilerplates while they may not even need it. Recently there was a great article published on Smashing Magazine considering web design trends. I think the situation is very much similar to web development here – midless following, well, let’s say best practices or using latest innovative tools without even asking whether this exact solution is the best thing that will suit my needs.

And let’s face it – it’s also partially caused by a bunch of CSS3 generators which got developers used to repasting few lines of code without a blink of an eye and then attaching CSS3 PIE to get for example gradients working in IE.

This is just example but I think we’re facing a bigger issue here – the automation of development processes not always means good quality code. As Paul outlined there can be obvious performance issues caused by loads of javascripts, several unecessary stylesheets, etc.

Leave a reply