Our index.html page contains a few tags that we need to fill in:

<title></title>
<meta name="description" content="">

For the title tag for our project, let us enter the following:

<title>Home | Sun and Sand Festival 2012, Dakar</title>

The meta tag with a name description is useful when the site is listed in search engine results. This tag would be used to render the snippet of text explaining what this page is about. Let us set this to the following:

<meta name="description" content="Sun and Sand Festival is occurring between Nov 12 to Nov 16 2012 at the Ngor and Terou Bi, Dakar featuring performances by top Senegal artists">

Adding favicons would be the next trivial thing that most of us forget to do when we start a project. This is the next easy goal that you can reach, before you need to start thinking about the code you will be creating.

Favicons help in uniquely identifying your website. As the following screenshot shows, having a favicon makes it easy to tell which tab or bookmark you want to visit:

Touch icons are useful when your page gets added to the home screen on iOS (as shown in the following screenshot on the right-hand side) and Android devices (as shown in the following screenshot on the left-hand side):

HTML5 Boilerplate comes with a set of icons in the root folder that are of the right sizes for all the required icons for both touch screen icons (used by both Android and iOS devices) and favicons. You can use them as a guide when you are working on your icons.

HTML5 Boilerplate comes with the following set of icons:

The rationale for why we have so many icons has been documented by Mathias Bynens at http://mathiasbynens.be/notes/touch-icons.

If you have the graphic elements necessary for creating icons, you can get started with adding these icons to the root folder of the project. It is likely that you would forget to do it later when deadlines loom.

For our sun and sand festival example, we already have critical graphic elements assembled, the following screenshot shows the icons generated from the PSD template:

If you already have a list of libraries that you will be using, you can start adding them into the folder.

HTML5 Boilerplate comes with the latest stable version of jQuery, so you already have that. If you are inclined to use other libraries such as jQuery UI, you can copy them over to the libs folder.

Suppose you would like to use jQuery UI for your project, available at www.jqueryui.com, then copy the latest version of jQuery UI to the libs folder and then at the bottom of the markup in index.html, refer to it using the script tag.

Using a Content Delivery Network

By using a Content Delivery Network (CDN), we can reduce the number of resources to serve on our web servers and by referring to resources that are universally hosted by Google or Microsoft, it is more likely that the file will be cached, as a lot of other sites the user visits will also be referencing this particular resource.

If you paid close attention, you would have noticed that the source for the script that links to jQuery is different from our jQuery UI source. This is for two reasons, which are explained in the following sections.

Protocol-relative URLs

Typically most URLs that link to assets on the Web start with http://. However, there are occasions when the page is hosted on a server that uses encrypted communication. So, your page will be served with https:// instead of the typical http://. Alas, as your script source is still referenced with the http:// protocol, IE will throw a nasty dialog asking the following question to the visitors on your page:

You definitely do not want your visitors panicking over this. So, the easiest way to prevent this is to remove the protocol (http:) part of the URL completely, as follows:

//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js

This way, the browser will use whatever protocol the page has been served with for the request. You can learn more about protocol-relative URLs in the Appendix section.

Of course, this means if you are testing locally, and if you view your page on the browser, the browser will use a URL that looks like file://users/divya/projects, and hence the browser will attempt to look for a jQuery file using the following URL:

file://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js

This request will definitely fail, as there is no resource locally at that path. Hence, if you are using protocol-relative URLs, you need to set up a local server to test your files. This is easily done on a Mac or Unix-based OS by navigating to your project folder in your shell interface and executing the following command:

python -m SimpleHTTPServer

This will start a server and your project's index.html file will be available on http://localhost:8000.

Tip

If you are on Windows, copy the Mongoose executable (the latest version at the time of writing was mongoose-3.3.exe) from code.google.com/p/mongoose/ to your project folder and launch it. Your project's index.html will then be available at http://localhost:8080.

Google CDN hosting

Google hosts a lot of popular JavaScript libraries. A list of all libraries hosted on Google's CDN is available at code.google.com/apis/libraries/devguide.html.

We could take advantage of Google's CDN for jQuery UI too, as it is hosted on it. Let us convert it to use Google's CDN by changing the source of the script file from js/libs/jqueryui-jquery-ui-1.8.17.min.js to the following:

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js

But wait! Let us take a look at how we refer to jQuery CDN in HTML5 Boilerplate. This is shown in the following code snippet:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.8.2.min.js"></script>')
</script>

Do you notice how we also refer to a local copy of the jQuery file? We do this just so that in the event Google's CDN fails, we still have our local copy to use. Granted this does not happen often, but it is useful to have a fallback when or if it does.

The statement window.jQuery || document.write(…) does two things. These are as follows:

• Check if the jQuery object exists: If it does, it means Google's CDN worked. If it exists, do nothing.
• If the window.jQuery object does not exist: This means Google's CDN failed; it immediately renders a script tag with a reference to the copy of jQuery in the project's libs folder. This tells the browser to immediately make a request for that resource.

We can do something similar for jQuery UI.

All jQuery plugins are objects within the jQuery object. So, we only need to verify whether the plugin object exists and if it doesn't, load the copy of the plugin in the libs folder, using the following code snippet:

<script>window.jQuery.ui || document.write('<script src="js/libs/jqueryui-jquery-ui-1.8.17.min.js"></script>')
</script>

Hence, our complete script file for referencing jQuery UI would be as shown in the following code snippet:

<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js "></script>
<script>window.jQuery.ui || document.write('<script src="js/libs/jqueryui-jquery-ui-1.8.16.custom.min.js"></script>')
</script>

Note

There are other CDNs that host libraries too. The cdnjs.com URL hosts a lot of JavaScript libraries. Microsoft also hosts a few libraries on its CDN; the list is available at www.asp.net/ajaxlibrary/cdn.ashx.

This is another of those minor actions that gets forgotten when deadlines come calling. HTML5 Boilerplate already provides the ready snippet for you to use. All you need to include is the unique identifier for your website.

Note that HTML5 Boilerplate includes the snippet at the footer of the page, which means the metrics get sent only after the page is loaded. However, there are a few people who believe Analytics should occur even before the page gets loaded to measure who leaves the page even before it has completed loading. If you would like to do that, you should move the Analytics snippet to just above the closing </head> tag in the index.html page.

humans.txt makes known the people who have worked on a website. Anyone can simply visit example.com/humanx.txt to immediately know the names of people who have worked on that website. Add your name and those of your team members to the humans.txt file that comes within HTML5 Boilerplate.

For our sun and sand festival example, the following screenshot shows how our humans.txt will look: