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.
58 Comments
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 🙂
Could not a agree more! Well Said!
J&L
Your meta tag is invalid HTML. Strip the last slash.
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.
@Ronni no it isn’t. It is valid HTML5 coded using XHTML style elements as that is my personal preference.
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.
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.
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…
+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%.
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.
The HTML5 boilerplate you listed is exactly the same as mine (although I’d add the lang attribute to the opening html tag), and I only add things as and when needed. A lot of these boilerplates etc. out there contain an awful lot of code that most sites simply don’t need to be loading and burdening their users with.
Horses for courses as is often said.
Lemme introduce mine:
:>
I agree
+1
I would recommend changing to (or the appropriate language code). Without defining the document language, your boilerplate already violates a Level A Web Content Accessibility Guideline.
Blast! Code was stripped. Change html to html lang=“en”.
I can totally get behind the whole “don’t include libraries/polyfills/etc if you don’t need them” sentiment. But as for wrapping some IE conditionals around html/body/etc in order to give you readymade CSS classes for older browsers, where’s the harm in that?
I’ve come to lean on “.lt-ie9” etc in order to do small IE tweaks like giving specific elements layout (or whatever needs to be done to them) without having to think about IE-specific CSS files and the like. I’ve just worked it into my personal starting point/bag of CSS tools. I can’t imagine that it really introduces so much overhead that it makes sense to strip them from any project that (happily) doesn’t need IE tweaks/fixes?
Rachel, please reformat this post suitable for framing. 😀 I love it. Well said!
I thought I was starting to go crazy with all these boilerplates chucking so much starting code at me. I kept thinking, “but I have never had any problems by not including this stuff in my website.” It’s reassuring to see others are on the same page as me.
I absolutely love it when someone else writes what’s on my mind, before I manage to formulate it. Couldn’t agree more with the content of the article.
@Joel. There’s no immediate harm in including IE specific styles using conditional statements. But if you don’t need it, why bother? It’s not much different from using a reset.css to reset EVERYTHING compared to just setting the values you need when you need them.
Why add extra bloat if you don’t need it? Designers (the good ones) know not to decorate, they know not to add something just because it looks snazzy, they add something because it serves a function, and then they make it look snazzy (granted; blatant simplification). But some front end devs – or developers in general could really learn from that.
– No you don’t need jQuery to make a link consistently open in a new window.
Thanks – a post that blows away many cobwebs. I do find HTML5 Boilerplate very useful, but as a kind of best practice scrapbook to dip into when required, not as a starting point. To be fair the Boilerplate authors do stress it should be used piecemeal, not necessarily in its entirety.
Agree with lots of your points, but disagree on the use of your boilerplate.
It’s easier to throw stuff out, then to find and fetch it..
Hence the useage of boilerplates (general use is also wrong cause lots of ppl think of it as a must-use-all concept). See also: the idea with some ppl that Bootstrap is a “theme”..
Best way to work imho is write your own boilerplate, pick up best practices from the various very good resources around and have ‘em somewhere as a starterpack, foundation, base, boilerplate, whatever name suits you. And even then throw out the bloat..
While I understand the motivation, I dont agree on that “boilerplate” you have. At least I would include a normalize or reset. They decrease drastically the amount of fixes to do in old IE.
While I agree that is a good practice to understand the pieces of a boilerplate and know what you dont need, the one you use is lacking basic common features.
IE Conditional wrappers are awesome, and a real credit to Microsoft. I’m happy to hear that IE10 is supposed to be bleeding edge and standards compliant, but am terrified to hear that it won’t support this trusty feature.
I’ve developed IE trust issues.
I love this, right down to the self-closing slash in the meta tag. 😉
Most of the time I’m building sites to run in my CMS, so I don’t completely start from scratch, but when I’m first building page templates from a provided design file, I begin with something very similar to this.
I’ve tried a few of the boilerplates that get a lot of attention these days, but too often there are bits I don’t need, and just as often, I simply disagree with certain elements of the approach.
I especially like keeping things simple in terms of handling IE8 and earlier, and I think you really nailed it.
Well done!
This article couldn’t have come at a better time for me professionally. Recently I stripped out unused helper classes from my HTML5 boilerplate
among other useless crapI was leaving in a clients project just because. Also, if I’m not gonna support IE6 then why do I need the conditional comment on the html tag? The answer is I don’t so it gets deleted. Then Jeff Croft steps into my Twitter feed and all of a sudden I’m now a SASShole for life.Garbage code clutters bandwidth…enough said. Great article!
Funny that the way to work in this industry is basically still the same after more than a decade. Despite all this nifty solutions and tools I still practice the approach “Build for the best and test for the rest”.
And with recent progress in the quality of “the rest” that has only become easier if you know how you “build for the best”.
A great refresher this article!
Thanks.
“Above all, avoid boilerplate comments: Never put in a comment simply because you always put a comment there.”
pp6 from Eloquent Ruby by Russ Olsen
http://eloquentruby.com/
Saved 30k by just removing all my css comments. Screw view source its all about the users and speed is more important than betting on the small chance a developer wants to look under the hood. If you wanna know how its done read a book, contact the designer personally or use a developer tool to be a detective.
I’m new at this and have found this most insightful and interestingly being new I built what I wanted and could. Then I figured out how to make it fit in with older browsers. Everything I read contradicts the next. But this makes total sense. I feel great.
Cheers
I love the article. As a newcomer to this web by world I find everything I read conflicts with the next. But ‘build for the best and test for the rest works for me”. I have made one 4 sites each one better than the next. With my limited experience what you say makes sense.
It makes me happy.
Cheers
This is a really valuable post; I’m consistently surprised with the rate at which web developers lately seem intent on complicating their work, and troubled by the current tendency to acquire third-party legacy code issues; aren’t our own usually enough to cause us grief?
Yeah problem I think is we have all these plug and play solutions that allow people who don’t know who to do it any other way, do things. I often see people including 5 jquery libraries just to do a simple layout thing. That is like 10 lines of CSS. When asked why not use CSS they go oh didn’t know you could do it. I saw someone doing this on a site and thought you had to use jquery to do it.
Use to be you had to know how to code, now it’s turning more into knowing how to plug and play an api into code to do the work for you, but they all come at great costs. Helped one person take a site that was nearly 5 mb in size for default page, down to about 500kb. We started by stripping the 25 libraries he had loaded in but weren’t using. Stripped it down to 1 library and to be honest if he knew how to code some javascript he could of got rid of that one, but I let him have 1, cause it did make his life much easier being a less experienced coder.
The world is changing, which is a good thing I love having GIMP as an option over photoshop and while I am a digital artist. I’m not, no formal training, etc just watch some videos on how to. I find myself daily learning the proper way to do things that I did wrong. Same overall look sorta, but the image is half the size and renders / scales better. So while I scold web developers, I get scolded when I do my digital media. Key is for us to try and teach people to build simple first then add on top of it.
But even that is a challenge. When I build applications for work, I never focus much on formatting or design, just crude layouts, etc while I work to get everything programmed and functioning. Then I go back once everything is hashed out and make it pretty. But every time I go and demo the current state for the bosses they focus mainly on why it doesn’t look great format wise. I get tempted myself to toss in some libraries to quickly make it look pretty, but it’s just a waste. But I can see where having all this free and quick broiler plate seems to pay off. Till you build your 50th site on the same server and have to go buy another one, vs just trimming site size down, or your bandwidth bill actually becomes YOUR problem and not someone elses.
Almost a year ago me and a bunch of other few ppl got an app on which another team worked for three years and produced nothing usable. It was a web app, not really small.
The guys before us used CSS, plain HTML and hand-knitted Javascript.
We started out with a complete rewrite using qooxdoo, which does not require one bit of CSS or HTML, but exclusively JS code.
In one year, we produced the full app, working as intended. IMO, without a JS framework to allow us bypass layout issues we wouldn’t have gotten that far in five years.
My take on the issue: it all depends. If you are really doing a templates-based web site, maybe even one composed of basic static pages, the approach promoted by this article is the sound one. If you actually do a heavy-weight web app, with hundreds of dialogs, data grids, trees, complex forms etc., use a framework or you’ll break your neck. What the framework provides isn’t just layout. A framework takes over all layout issues, making all browsers equal, and lets you focus on the functionality, while also allowing you to manage complexity.
One more thing: the framework approach also takes care of the bandwidth optimization thing for you. And if you really only work with data, using a RIA framework really pays off – transferring JSON over the wire is cheaper any day of eternity than transferring HTML.
Very good points. I hate just tying a bunch of libraries/frameworks together. It can create such a mess.
I would like to ask a question though: What’s your opinion on UI frameworks such as Twitter’s Bootstrap CSS?
Well said! I was wondering if I was a fool for not using Bootstrap or HTML5 Boilderplate on my projects. I honestly prefer creating my own boilerplat code with my own default CSS that makes sense for me.
Sure I might use these frameworks for inspiration, but at the end of the day the work is much easier when you’re not trying to figure out someone else’s mind map i.e. their coding, naming conventions etc.
I agree with keeping only what you need. That’s what I do with html5 boilerplate. It’s an amazing tool. I especially like the .htaccess file. But even this, I strip it down. It’s good practices that agree with the ideas in the book “Even faster websites” and the one before. Like stripping Etags if you don’t need them. Or caching for example. Html5 boilerplate is not bloat at all, there’s a lot to learn from it too. We can’t stop learning and stay stubborn because our ways work. Technology progresses fast and we have to keep pushing the boundaries!
Great comments here. I’ve taken, for me, the best of the frameworks and resets to compose my own starter boilderplate and segmenting out “just in case” css layout adjustments into a “toolbox.” After initial build I can delete what I haven’t used.
Agree with what your saying, there are some gems in html5 boilerplate but when it comes to them defining what structure you should use for assets etc or libraries you should I simply disregard them and pick and choose useful pieces from them.
Those kind of boiler plates tend to cover all bases which is great but its up to you as a developer to decide what suite the project.
Some of the best parts of html5 boiler plate for me is paul irish’s conditional html tag idea and some of the great stuff in .htaccess for easy gziping etc
Jared,
Technically the boiler plate doesn’t fail the WCAG A checkpoint, because there is no content, so no language of content to define. lang=“en” doesn’t make it pass the checkpoint, because you are making the assumption that any content added will be English.
I take the exact opposite approach with my boilerplate… Instead I try to include anything and everything I commonly use, jQuery sliders, sidebars, footers, header, CSS for logo replacement in the header, mixins, etc… I find its easier to delete stuff than to add it… Going through the project and deciding what elements you need and which you don’t is very helpful. Its also helpful for maintaining my code into the future because its all the same… class names, css structure, etc have the same starting point and are easier to keep up to date…
That’s exactly my HTML5 template when I begin typing. 🙂
As I just learned you can even go a step further. When coding HTML5 pages you can leave out <head>, </head>, <body> and </body>. HTML5 doesn’t need those tags obligatory.
I agree wholeheartedly, there’s no better way to start than keeping it simple. I love your HTML5 boilerplate, clean and concise as i know i get confused with all the jquery plugins that are out there! I love css3 and getting to grips with all the new features as i know a lot of people that dissable javascript and then all the jquery goes out the window!
Thank you for the article 🙂
Couldn’t agree more. Thanks for having the guts to fight back against the likes of Heilmann and his Smashing Magazine cohorts and vote for sanity. So yeah we’ve got a good scenario in terms of innovation, but it’s not perfect whereas it may well be in a couple of years. So why shiv all sorts of crap into our sites instead of just waiting two years? No reason! I’d much rather go back and change a few divs to asides, header, footer etc tags in my templates in two years time than put up with the joke that IE.Old doesn’t apply CSS to those tags at all. Recently got caught in a situation like that after being forced to work on a project using the almighty shiteload of web development intelligentsia political correctness: drupal, html5, etc (you name it, it was thrown in there). Madness.
I can’t agree with article. When I start project I know big part of problems and I know that I should to solve them in future, so I make some investigation to make product features – not solution for current moment. There is big problem for programmers to make quick solution without thinking about future.
Also, there is a big problem when people make so global solutions that so hard to maintain – and boilerplates is not problem in this case.
Developers should be in the middle of this problems and it can be learned only with practice.
ps. sorry for my bad english
Problem #4
HTML5 elements, even when forced to be recognized via javascript and set to display:block via CSS don’t have any styles applied when you try to print them.
Do you have a simple workaround for this?
Great post, it was about time that somebody clarifies the usage of toolsets, libraries and frameworks out there.
YAY! Someone talking sense, so pleased to read this article and the comments. No longer feel so alone!!
Hey
you are absolutely right. some time ago i came across those tamplates but honestly i didnt got that idea of having too many stuff which actually you dont need it at all in your page at first. it seems you are reading my mind 🙂
Thanks
Love from Dubai
Excellent Article. Honestly I have my own version of boilerplate & i have customized it as per my code needs.
Boilerplate comes with a minified version of Modernizr. While Modernizr is an amazing library I don’t use it in all of my projects. I rather use HTML5 shiv with conditional tags for IE 8 & below.
Also i ask my clients whether to use polyfills like CSS3 Pie for rounded corners and all. The polyfills have advantage as well as disadvantage including degrading page speeds.
Lastly to conclude, if we remove the unwanted code, the page-load time would decrease and thereby create better user experience.
Man would I sell my soul to have a developer like you to work with.
For my experience here at where I work right now (5/21/2012) the use of boilerplates or polyfills is not even the problem.
The problems I have to deal with are because the developers (off-shore and in-house [with one exception]) I work with don’t even have the slightest clue what an HTML5 boilerplate is, dang, NOTHING today is being developed in HTML5 for that matter (and there are no plans to do so in the near future either), and we just launched our new corporate site a few months ago and they weren’t capable of making the CMS use HTML5 after I practically begged them to figure it out.
Right now it would be AWESOME to have the problem of trying to “Stop solving problems you don’t yet have”.
I tell this to my design team all the time. They often suggest some jQuery plugin (or the jQuery UI library and all its bloat) to solve a simple issue, like “make a fading image slider”. These plugins often come with 10 or 20 different transitions, or different UI elements that we don’t even use, and half the time they interfere with other javascript we have running on the page.
Most of the time, its easier to just write your own. That way, you know what’s in it, and when it breaks, you know how to fix it.
Very objective article.
Waht a CMS was used to develop this (also greenbelt.org.uk/) site?
You had me at “Here is my HTML5 boilerplate”… Mine looks exactly the same. I’ve always been a bit of a purist and so I hate adding unnecessary JavaScript etc. Nice article, I couldn’t agree more.
Good read, I try to keep the absolute essentials in my boilerplate – making it a good fit for every project.
I’m actually currently working on my new site. I’m trying to do it in HTML 5, and my business partner always wants to use all these fancy templates, but I prefer your method as well.
I also prefer to write code myself so I know exactly how to fix it as someone else mentioned. Thanks for the post, it’s always good to feel validated that someone else has the same mindset!
I agree with this totally. Using third party tools usually just give extra that is not needed and plus this separates a true developer from a non developer.
Great post and this problem still looks to be on the increase. Jeremy is absolutely right, we are bombarded with useless libraries because perhaps there is little less chance that things would break. it’s just not the right way!
Warm regards, Jose
PS. Looking forward to my weekly email subscription!
Well said! I was wondering if I was a fool for not using Bootstrap or HTML5 Boilderplate on my projects