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.