In the I've outlined what the Sitefinity Boilerplate project is and where to get a copy.

When you unzip the file or clone the repository you’ll see the sfboilerplated folder with inside the familiar folder structure of a Sitefinity Template & Theme. You can go straight ahead and copy the entire folder structure and files into your Visual Studio solution, publish it and you’re already done! But if you don't understand what 'rtfm' stands for, you might want to continue reading...

This file contains the general release notes, changelog and a short description to each file.

Sitefinity doesn’t come with a favicon so this file contains all the precomposed icons for all the iPhone/iPad & Android devices, which you can just paste in the rootfolder of your project. The favicon.ico comes in 2 flavors; the default is the smallest one (16x16) and is a regular favicon.ico as we’ve all known them for years.

The favicon-ie.ico is IE9/IE10 enhanced and supports site pinning. This version consists of 64x64px, 32x32px, 24x24px and 16x16px so is considerably larger but required when using Sitepinning. If you want to use this version, just delete the other favicon.ico and rename this file.

Windows8’s Metro desktop will support site pinning onto the desktop and no, we don’t need to name those files in our master pages, browsers will detect them by themselves. For more information checkout the MSDN documentation on pinned sites.

App_Master folder

As mentioned before, there’s only 1 masterpage (template) inside SF|Boilerplated. When you open it up in Visual Studio (or your favorite editor) you’ll immediately see familiar bits and pieces from the HTML5Boilerplate project. We’ll dive into a more detailed look in a minute…

App_Themes/sfboilerplated folder

This folder contains the familiar theme structure of Sitefinity with a global, Images and Styles folder. Inside the Styles folder is an optional ‘BrowseAndEdit.css’ file, containing all the necessary styles to support Browse and Edit functionality. If you do, just move it to the Global folder and add it to cssLoadOrder.xml. If you don’t – you don’t have to do anything.

The Global folder contains the ccsLoadOrder.xml, which describes which .css files get loaded with Sitefinity and in which order. Next you’ll see 3 files called ‘normalize’, ‘layout’ and ‘layout_transformations’.

The ‘normalize’ file contains everything needed to ‘reset’ or better said ‘normalize’ all the different browsers from different vendors (IE, Chrome, Firefox, Safari & Opera are fully tested).

Normally you don’t have to change anything to this file, unless you’re concerned about W3C validation. In which case when you edit it, you’ll see hacks and compatibility breakers stored in a different region so you can easily delete them.

The ‘layout’ file is the stylesheet file for your project. On the top you’ll find a few lines establishing a vertical rhythm and at the bottom you’ll see the familiar non semantic helper classes. Just write your project’s markup in between and no harm can come from anything ?

The ‘layout_transformations’ file is where your media-queries for responsive design and mobile friendliness are stored. By default only 1 ‘mobile-sized’ media query is defined and one print-friendly media query.

If you’ve taken a peek inside the folder, you’ll actually see there are 3 types of files for ‘normalize’, ‘layout’ and ‘layout_transformations’. For each file we’ve provided the development version (.css) the minified production ready version (.min.css) and a LESS version (.yui.less).

When you’re not using .less or the production ready .min.css files you can safely delete them.

JS folder

This folder contains only 3 files; the first being standard jQuery.

The jquery-1.7.1.min.js is by default loaded from Google’s CDN, this file is used as a fallback in case the CDN is unreachable. It is just provided for convenience and is the same version as Sitefinity expects.

The is a file referenced by the Masterpage. This file contains all the Javascript needed to be loaded in the <head> section of your template. By default it already contains a minified, production ready version of Modernizr (which is needed for fallback browsers).

The script.bottom.min.js is also referenced by the Masterpage and can contain any project Javascript or jQuery you’d like to be added. By default this script is called before the body closing tag (preffered way of loading js) and after jQuery is loaded.

The sfv5-1column.Master up close and personal

When you open the Masterpage, you’ll notice 3 Sitefinity lines for compatibility, directly followed by the HTML5 doctype declaration. Be sure to change the lang=”en” if your Masterpage isn’t going to be English so browsers will correctly identify the language.

The meta tag 'http-equiv' will break W3C validation but it will ensure that Browsers will try and load the latest version (looking at you IE9) and not quirksmode. The 'viewport' tag is added for mobile media-queries.

Next you’ll see 4 'ms-application' and 1 'application-name' meta-tags, these are the essential bits for IE9 sitepinning, you can either remove them if you don’t want it or change the content values.

The ‘title’, ‘author’ and ‘version’ are inserted for future Telerik layout builder and Thunder support. And the <head> section ends with the already described link to the file.

Right underneath the <body> tag, you’ll see 1 line urging users to upgrade their browsers, if you’re still supporting IE6 – remove this line. Right after the <scriptmanager> you’ll notice an ‘accesskey’ href for screenreaders. If you update the id #cpw_content, be sure to update it in the href as well. It utilizes Sitefinity resource translations for the hidden text.

Inside the ‘PublicWrapper’ is where all the magic is finally happening. The Masterpage is divided into 4 different sections to describe the base document outline. These are the ‘header’, ‘banner’, ‘content’, ‘footer’.

Let’s look at the ‘HeaderWrapper’ more closely…

The wrapper consists of a <div> and not a <section> because we’re containing 2 different landmark sections. A ‘role’ has been added to each part to describe the correct functionality for accessibility according to WIA-ARIA guidelines.

Classes have been assigned to correspond with Sitefinity’s backend page edit region layout-editor. Wrapper classes are ‘sf_cols’ and containing divs are ‘sf_colsOut’.

By using this naming convention, we ensure that our regions will act similar to regions added inside Sitefinity and by adding style rules to these 2 classes, we also ensure end-clients won’t get unexpected results.

The ‘FooterWrapper’

Near the bottom of the Masterpage, you’ll find the ‘ScriptWrapper’. This wrapper is defined outside of the default PublicWrapper, so it just sits at the bottom of the page with none of the styling applied.

First we’ll load jQuery from the Google CDN, with a local fallback. Next we’ll load the async Google Analytics snippet. If you’re using Sitefinity’s Analytics widget, you can just delete it.

Underneath the reference for ‘script.bottom.min.js’ we’ll see one final placeholder. This placeholder will/can/should act as a placeholder for Sitefinity’s page editor. Nothing added to this region will be displayed on the website. Having a separate region inside the page editor ensures that dropping style widgets or script widgets won’t break a user’s visual lay out of the page and gives us a nicer user experience.

That’s it, have fun! Use it, share it and please comment on it to make this an even better boilerplate…