First of all, you can find the home page for the project at http://html5boilerplate.com/. The site offers a quick overview of HTML5, but does not provide much context to why HTML5 Boilerplate is useful and why it was created at all.
I won't go extensively into the history of HTML5 Boilerplate. This book is mainly focused on how to do stuff, not how stuff happened, so I will try to explain just enough of the background to let you know how it works, with the hope that your future use of HTML5 Boilerplate with 320 and Up (as well an any other framework) will be with enough understanding to help you solve future problems.
In essence, HTML5 Boilerplate was a project started with the intention of creating an HTML page that had all the components one would need to make an effective, cross-browser web page; it also utilizes all the goodness available in modern browsers that support the modern HTML5 specification.
If you want to know more about what I mean by HTML5 specification or what the difference is between a modern browser and an old browser, then I encourage you to do some searching and reading. Any links I leave for you are at the risk of being out-of-date soon. But, briefly, HTML5 is a specification for what browsers should do. It is an effort to make all browsers support the same or similar features so as to make it possible for web developers to make a web page and have it behave the same in all the browsers. This is not a reality yet, nor do I think it will ever be; to be fair, though, things are a lot better than they used to be.
So, currently, as a web developer, in most situations, you will most likely have to support, at a minimum, Internet Explorer (IE) Version 8 and up, Firefox 4 and up, and the current release of Chrome (Version matters less with Chrome, since it has always encouraged users to update). Note the challenge here. The current versions of all the browsers, except Chrome, are higher than those you must support. Also, chances are, if you are making a site at the time of writing, you may actually need to support older versions of these browsers as well as a few more browsers, depending on your user base. And those are just the desktop versions; forget about all the mobile versions of those browsers as well as the Android flavor of WebKit, which has a bazillion versions out there.
Knowing this, you can see why I and so many other frontend engineers evangelize for simplicity in frontend design. A simple design has a high likelihood of giving a good experience to the end user as well as something approaching consistency.
But, you don't get that experience and consistency without some effort. HTML5 Boilerplate goes a long way towards making that effort on your behalf. Let's walk through it for a few pages to better understand how it works. As you read along, I suggest that you pull up the index.html file from the before directory in Chapter 1, Mobile First – How and Why. This is the boilerplate version before we added anything to it. Let's start at the top!
The code for conditional comment looks as follows:
<!--[if lt IE 7]><html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="en"> <![endif]-->
This code is nested inside comments but has some conditional logic. Only Internet Explorer has the super powers to use this logic. The previous example only renders the HTML code inside the comments if the browser executing it is a version less than IE7, thus the syntax [if lt IE 7]. You can infer that different HTML tags are rendered based on the version of IE. You can use the classes in this HTML tag to make special styles that are typically necessary to deal with the shortcomings of these older browsers.
If you jump ahead a bit, you will see the following conditional comment:
<!--[if (lt IE 9) & (!IEMobile)]> <script src="js/selectivizr-min.js"></script> <![endif]-->
This includes a JavaScript library included in the 320 and Up framework that allows CSS3 selectors to work in browsers older than IE9.
So next, within the head tags, you will see some meta tags that are used by vendors to perform a magic trick. The first one to take note of is as follows:
<!-- http://t.co/dKP3o1e --> <meta name="HandheldFriendly" content="True"> <meta name="MobileOptimized" content="320">
You can visit the link provided in the comment if you want further details on meta tags. I encourage you to do so.
To summarize, these meta tags help mobile browsers know that they can render a page that isn't only intended for desktops. Get used to this as there is a lot more of this kind of thing coming ahead.
After this, there is a bunch of comments that allow you to create icons for the Apple devices. These icons are cool if a user wants to create a shortcut for your website. It creates an icon for your website just like an app would have. If you want to take advantage of this, you need icons of all the dimensions, and you need to either place them in the path already specified or edit the path so it loads your icon files.
There are still more Apple-specific meta tags. For many, as you can see, you just need to fill in the blank field (for example, apple-mobile-web-app-title).
<meta name="viewport" content="initial-scale=1.0">
The previous line of code makes sure that the page doesn't get zoomed in as long as you have the content field in the next code line set to yes:
<meta name="apple-mobile-web-app-capable" content="yes">
In the next section, the one labeled startup images gives your web page more app-like functionalities. When users launch your site from their home screen, these images will fill their screen until the page loads. Again, you will need to provide images of all the dimensions listed and put them in the correct path. However, you should know that this particular block of markup can potentially be removed and applied with cleaner code. You will learn about this in a moment when we go over the helper.js file together.
Mercifully, the next set of tags for Windows 8 adds almost no new work! This tag can and should share the icon you created for Apple, and will appear in those nifty Windows 8 tiles. You can set the color of your tile in the following tag:
<meta name="msapplication-TileColor" content="#000">
Please, please, I beg you. Set it to hot pink.
Whew! We're done with the head!
The rest isn't terribly surprising. We include the following scripts below the footer, and in order:
There is no problem with making your site this way but I often combine plugins, scripts, and helpers into one file.
The helper.js file should come before the script file; otherwise you can't call the functions in it. If they are correct, just rearrange them and you'll be good to go.
The last thing is I want to give you an overview of the helper file, since that is a part of the HTML5 Boilerplate.
The code in this file is really helpful. The comments in it explain what each function does for the most part. Nonetheless, I'd like to highlight a few things and make sure you know how to implement them.
Basically, to call any function in here, just find one in the file you need (or just want to try) and put (); after it. That is JavaScript's way of executing a function. For example, the first usable function defined in this file (you can tell that they are functions because they have the word function in them) is as follows:
MBP.scaleFix = function() {…If you want to use this function, just add this to your script file:
MBP.scaleFix();
Et voilà! You just called this function. Now let's go through a quick rundown of what the most useful functions in here do. Keep in mind that many of the items in this script are used by the functions themselves; so, if you try to use them, they might not do anything, especially the ones that don't have the word function in them.
MBP.scaleFix: This function stops an annoying bug that happens in iOS. This bug manifests itself when a user rotates the phone from portrait to landscape. In landscape, your lovely web page will end up running off the edge of the screen. But, no worries; this script fixes it. So you should use it.MBP.hideUrlBarandMBP.hideUrlBarOnLoad: These two functions are callable but you are more likely to useMBP.hideUrlBarOnLoadto do pretty much what it says. This function is useful on mobiles because, once the page loads, it scrolls the URL bar up out of the view, thus saving precious screen real-estate. This is super useful for users who use Safari on an iPhone. I suppose you could callMBP.hideUrlBarbut I have a hard time imagining a scenario where you want to directly call it without freaking out users.MBP.hideUrlBarOnLoadcallsMBP.hideUrlBar.MBP.fastButton: This is a function to get around a feature of WebKit browsers that introduces a slight delay when users touch a link or button. Use this with caution.MBP.splash: This script can replace theStartup imagesblock of commented-out code that we were discussing previously. It is provided in the head of the boilerplate that we were previously examining. If you've forgotten about it already, go back and read it over again. I really like the cleaner page when using this JavaScript to replace all that markup in the page, especially considering that only a few users will ever see this splash screen. In fact, if you go grab the most current version of HTML5 Mobile Boilerplate, instead of the index page provided in the current (as of this writing) version of 320 and Up, it won't have that block of markup with all the splash images.MBP.autogrow: This feature is great if you have forms on your responsive site. It makes<textarea>grow as a user fills it.MBP.enableActive: This is another awesome enhancement that enables the active pseudo class in Mobile Safari and is nice for user feedback on those buttons that tend to lag a bit (unless you are brave enough to useFastButton).MBP.preventZoom: This does what it says. The default behavior of Mobile Safari is to zoom in when an on-focus event happens. This is really inconvenient for users as they have to then manually zoom out after they are done inputting text to an input field.
Now you know enough to go experiment with these in your own apps. For the most part, you will want to fire these functions when the page is loaded and ready, so only use those that you need in order to prevent bogging down small devices with loads of JavaScript.