Photo Credit: Ara Pehlivanian
At SXSW 2009, Paul Irish showed me his initial work on HTML5 Boilerplate and asked if it was something I would be interested in contributing to. It was a no-brainer to say yes. I was thinking about creating something similar myself (as I’m sure you were too!) We quickly ramped up production and released it to the wild about three weeks ago.
HTML5 Boilerplate is a compilation of best practices that would help any web developer get started on their code. It also catches some of the stuff developers usually miss when in a hurry to meet deadlines (e.g. print and mobile styles, making sure www and www-less domains redirect correctly, getting servers to serve the right content types for new or relatively unknown file formats and having a backup for jQuery in case the CDNed jQuery fails).
I heartily recommend that everyone delete some of the things that may not be applicable to their production environment, like if you don’t write unit tests, you may not want to use the unit test suite. You’re allowed to pick and choose!
Boilerplate is made up of snippets from all over! And they’re all documented! Here are some of the goodies you’ll find:
- Use of the new HTML5 elements without worrying about cross-browser compatibility.
- Optimal caching and compression rules for better webpage performance.
- Mobile browser optimizations.
- Build a better experience for all users with feature detection.
- A ready-to-use unit test suite.
It was great fun to work on this project because we had to think several times before including or deleting a snippet. We had to rationalize the existence of each. I also spent hours testing on several mobile browsers to check how the default mobile styles were rendered.
We aren’t done yet though, Paul is working to get a build script going which would automate some of the recommended performance best practices. Others have pitched in with WordPress and Compass ports. I makes me very happy to see so many people rallying behind it and contributing!
So, go have fun with Boilerplate. I bet you’ll have a brilliant insight or two, so feel free to fork and tinker with it!
FYI, the project is in the public domain, so you really can do whatever the hell you want with it :)
Web Development is a strange field. This is where, to use a weary metaphor, 1 + 2 will equal 3 today and 5 in six months (or other values based on which browser implements what). The specifications that browsers standardize on are in rapid and heavy development today, and browsers outdo each other in the race to implement the specifications as quickly as possible. This means that, unlike in other fields, self-learning is mandatory.
What I find perplexing is how often we outsource this learning to others. Many developers do not use certain standards because well-known experts have not expressed an opinion on it. Sometimes, unstable features find popularity because experts have explicitly endorsed them.
More troubling is that very few people take the time to read what the specifications say. Even Google ranks Sitepoint’s Reference, and W3Schools’ website higher than the actual standards when searching for CSS/HTML properties (and for a beginner, it is hard to know that the former two websites have nothing to do with the official standards body.)
Browser vendors too have a vested interest which is not immediately obvious to us. Vendors introduce vendor-prefixes for their own benefit and a few of these prefixes get into the specifications. But many of us are not aware of which vendor-prefixes have been implemented because they feature in drafts of upcoming standards and which exist because they fulfill something unique for that browser. This sometimes leads to frustration with browsers that do not implement the popular vendor-prefixes of another browser.
There are several outcomes as a result of this:
- Unstable/undesirable features get used quickly, leaving browsers with backward compatibility issues.
- We are not aware of the full impact of our choices on our web development environment in the race to use the latest and greatest.
- Useful features of standards remain unnoticed for a long time, because very few developers hear about them.
- It takes a long time for the common feature requests among web developers to bubble up to the Standards body, as they are unaware they can raise suggestions to the W3C.
- Websites become harder to maintain because choosing to use specifications that have inconsistent implementations among browsers leads to more work (or sometimes such choices can make content inaccessible).
- Web developers develop superstitions about browser vendors and web standards that are hard to alter (e.g. the poor opinion about Internet Explorer means, even when IE attempts to do something well, the IE team receives brickbats).
- Browser vendors seem compelled to implement similar features as that of the competition because some web developers find it interesting, not because they are useful.
I think, given the pace of development of standards, web developers need to be more curious: investigate, and learn about standards to make it easier to apply and contribute to them (Ben Schwarz talks about it too in his presentation Take back the web). There are many ways to do it. The following have always worked for me:
- Code, code, code. There is no substitute for practice. Instead of trusting someone else to test a standard, do it yourself. Check if it works within the restrictions you have or the environment your website needs to work on. Some features are implemented such that they slow down the rendering of a page, and if your website requires high performance they will not be appropriate. Some only work with some special caveats. Know the caveats as there are very few free public resources mentioning them.
- Review upcoming standards. Not all properties are supported consistently across browsers. We should find the limitations, as well as equivalent substitutes for browsers that do not support them.
- Refer to the guidelines from W3C. It helps to actually read helpful documents the W3C has published for web developers (e.g. HTML: The Markup Language and HTML5 (Edition for Web Authors)), and ask the experts about content that is not clear. Most of them are happy to help (provided you show that you have done your homework and ask specific questions). Remember, the intent of any implementation is lost while reading a “simplified” version of it. For CSS, individual browser documentations are also useful.
- Subscribe to the W3C mailing lists. Browser representatives and people who implement the W3C specifications talk about edge-cases and debate on specifications here. In particular, www-style and public-html-comments are two lists where you can comment on the CSS or HTML specs respectively.
- Learn to love the bug-tracking systems for browsers. If a standard behaves inconsistently despite following the specification, you should check Bug trackers for Mozilla, Webkit, Chrome, and IE 9 to see if it is a known bug (IE has also released IE Standards Support Documents, that details IE support for various web standards).
- Read what other people are learning about. Paul Irish has a list of 200 front-end development feeds to subscribe to. If this gets in the way, cull the blogs you follow.
- Interact with other web developers. Go to your local Web Design meet-ups and do not feel afraid of asking questions that you think sound stupid, because, if you had that doubt, it is highly probable that someone else had that question too.
- Always ask why. Why is there border-radius? Why do we need HTML5 form elements? Why Canvas? Knowing what caused standards bodies to approve property/element is useful as it gives an insight into where they are most useful, how they can affect your web development process and what to look out for.
We are at the edge of yet another big push to what it means to develop with web standards. Instead of waiting for other people to tell us what is best and what is not, I think it is important we do that for ourselves. Be curious, be free!