By Christian Heilmann CHAPTER 3None of the parts that make up the vanilla Web diet are new but they very
much warrant repeating. Here’s what we’ll cover:
- Build on what works
- Lack of support is an opportunity
- Browser-specific code cannot be trusted
- Use a mix of technologies, each for what it does best
- Ask questions
- Write as much as needed, not the least possible
- It is not about what you can add: it is about what we can’t take away
- Usefulness beats consistency across browsers
- Load only what is needed
- Analyzing effects beats adding FX
- Strong foundations beat a possible future addition
The first rule of the vanilla Web diet is to start from a clean slate. It’s
tempting to start with many of the existing HTML5 boilerplates or CSS
reset solutions out there, but let’s not do that right away.
The promise of an HTML boilerplate or CSS framework is to flatten
the differences between browsers and to allow you to start at a baseline
that apparently works across them. In many cases this really means a few
desktop browsers — many of which aren’t even in use any longer or will
never be available in a mobile environment. That’s why performance ex-
perts started advocating against boilerplates: they’re considered too heavy.
Making them more lightweight is one way of dealing with that issue, but
it also means we effectively create a code fork that needs maintaining
and upgrading should there be necessary changes in the original. There
is one true boilerplate — it’s called HTML5 and it is supported in a predict-
able manner by all current browsers and, especially, mobile browsers. The
whole idea behind HTML5 was to have a parser that is the same in every
browser, so let’s concentrate on using that, rather than extraneous padding
for browsing environments that are extinct.