I’ll be the first to admit that when I see a default template like HTML5 Boilerplate, it brings about a swirl of emotions.
On the one hand, I’m ridiculously intimidated by the incredible amount of knowledge and experience that’s been collected into one place for the benefit of front-end developers. So much so, that I wonder what I’m even doing in this industry, because it reminds me of how far behind I am.
On the other hand, I’m inspired, because there’s so much more to learn, and it’s exciting to add new nuggets of knowledge to my toolkit, and I can’t wait to hit the books and grow my knowledge base. It also helps when others express the same feelings about lagging behind. But I’m getting sidetracked.
Due to the fact that there’s way too much in Boilerplate that I don’t fully understand, and much that I probably won’t use in the near future, I decided to put together my own little HTML5 template that will become my personal “rock-solid” default (okay, it’s more like yogurt-solid, but whatever). And let’s be honest, Boilerplate is not just about HTML5, but about preparing a default environment for creating a killer cross-platform and high-performance web app. Sometimes I don’t want all that stuff; I want something more fundamental.
The Code
My little creation here is not meant to compete with any other templates. This is just a simple, HTML5-focused template with a basic CSS reset and some attached script files including Modernizr and the jQuery library. Also, the primary JavaScript file has a basic JavaScript design pattern that I’ve been using of late.
In addition to the basic HTML5 code to start you out, I’ve also included extensive commenting and some dummy content that makes use of some of the new tags and tag changes in HTML5. A lot of the comments are pretty basic pointers, because I want this to work especially for HTML5 beginners.
You can view the code and contribute on GitHub, or download the files:
You can alternatively download the stripped-down version using the button below:
The only comments included in the stripped-down version are ones that I felt were still necessary, so it’s not completely without comments, but it’s pretty bare in comparison to the regular version.
And yes, I’ve borrowed a couple of things from Boilerplate, but that’s inevitable due to Boilerplate’s inherent kitchen sink-ness.
Want a Little More? Use HTML5 Reset
HTML5 Reset is another project that was launched around the same time as Boilerplate, but is simpler than Boilerplate and easier to digest. The funny thing is, I actually didn’t even look at HTML5 Reset until after I created mine, because I assumed it was similar to Boilerplate, but it’s actually quite simple and more in line with what I’ve done here.
So use HTML5 reset if you want something that’s a little more ahead of the game and includes some mobile-related features.
This is a Work in Progress
In coming months (years?) I’ll be studying those other defaults to better understand some of the more advanced stuff they include (especially the mobile-related stuff, which mine doesn’t have any of) and I’ll be gradually updating mine to make improvements.
Thus, if you want a real template, use Boilerplate or HTML5 Reset. Or else you’re free to use this one and modify it to your needs. This is just my personal starting place, on which I’ll be progressively building.
Also updated jQuery version to 1.4.4, thanks to VP for the heads up.
Changed remote jQuery reference to minified version. Thanks to Florent.
<nav> element with a simple unordered list of links. Not sure how I missed that one, as it’s much more common than a secondary <header> element, which I did include. Thanks to Mikey’s tool Switch to HTML5, which reminded me.
I’m also considering removing the <section> element, because it’s not supposed to be used for styling. My use of it was just to demonstrate how it might be used to introduce a new heading structure. But now I’m second guessing if it’s ever useful at all. We’ll see, but use it with caution.
Originally neglected to credit Mathias Bynens with the asynchronous analytics code, so that’s corrected in the source.
<section> element. Now the main body has a <div> wrapping all the content, with two <section> elements nested inside for demo purposes. I think this falls more in line with what the spec says about section. I might try to incorporate an <article> element, too, but it seems pointless, because the dummy content is not really necessary for a template like this.
I’m curious about something with HTML5. I admit that I haven’t jumped on the HTML5 bandwagon just yet although I do see it as something I will have to learn (most likely sooner rather than later). However I was curious about something I saw in your template. In it you use html tags such as strong, b and em. It has always been my belief that the actual use of these tags is considered bad coding practice because they are something more inline for css to handle. In fact, when I first started as a web developer I had other web developers give me the riot act when I chose to use such html tags. So are these tags now considered good to use in HTML5? Are they now considered more of a structural element rather than a visual/look and feel type element?
After 5 years of not using these tags and instead using css to accomplish the same things it might be a bit difficult to make myself start using them.
Hey, Sean.
Well, what you’ve been doing over the last 5 years is not entirely accurate, but it was one way to go, and wouldn’t necessarily harm your documents.
I wrote an article on bold/italic in HTML5 here, which you might want to look at:
http://www.impressivewebs.com/bold-italic-html5/
Basically, in the past we were encouraged to use “em” and “strong” instead of “b” and “i”. The reason for this was exactly what you alluded to: The fact that “em” and “strong” don’t make any visual assumptions, so the actual styling is reserved for CSS. But it was still okay to use “em” and “strong” for adding an emphatic statement/word (with “em”), or for adding SEO or contextual importance (using “strong”). So you should still have been using them.
But now (as I describe in the article linked above), HTML5’s rules for those elements has changed. “b” no longer refers to “bold” in a visual sense, but instead refers to text that’s offset stylistically, but that you don’t want to have extra contextual importance. And “i” is no longer for “italicized” text, but instead is for text that’s in a different voice or mood.
So, under HTML5 best practices, we should be using all of those elements, but using them in the right way.
The html5 spec still seems to advice against using b or i unless there’s a really good reason for it. From the spec about the b element:
And about the i element:
Agreed. All of those areas markup specific types of content, some of which will affect the document structure and the hierarchy of the content. And they encourage that because beginners will often not use headings and other elements enough, thinking “b” will have the same effect.
But there are some areas where “b” is appropriate. Take for example this very article above. At the end, I’ve included an “Updates” section. I don’t want that to be a heading in itself (although it could be). I also don’t want the word “Updates” to have any SEO or contextual significance. I just want it to stand out visually. So I think wrapping it in “b” tags is the best choice.
hi Sean, i am web developer new in this feild just had 1 year of experience and want to continue this.
please give me suggestion about future scope of web developer and what skill set should i need to improve.
thankx in advance.
There are many skills/technologies listed here:
http://www.impressivewebs.com/skills-front-end-developers/
You don’t have to learn all of them, but many of them are required for front-end development. Most of the most important ones are near the top.
A few weeks ago I wanted to start using HTML5. I went to html5boilerplate.com and checked the code and that was reason enough for me to quit (at that moment). It was too ‘big’ (for example: all those IE6 fixes, while I don’t support IE6). You need to discover way too much. We need some simple stuff to start with, so I think you that you will help many people with this template. I’ll bookmark this page and when I have a new project I will use the template.
Very nice template – and not so complicated like Boilerplate… :)
Thanks for sharing.
Thanks for your work on this. Eric Meyer has just released an update of his reset for HTML 5 which may be handy to incorporate into your files:
http://meyerweb.com/eric/thoughts/2011/01/03/reset-revisited/
Yes, I’ve updated the CSS to use the new reset with a slight modification to prevent anchors from having no focus outline style.
I actually got the heads up about Meyer’s update from Paul Irish shortly after I published this.
I like your clever idea of adding in a query variable to the main style sheet. Now instead of responding with “It IS updated – you just need to clear your cache” I can get off my lazy butt and update that value myself! ;)
Yeah, and if you don’t ever want it to cache, you can just append a millisecond-based timestamp with the back-end code, so it will always have a unique URL and always look for a new version.
Of course, I wouldn’t recommend that, because you do want the CSS to cache, but it’s an option.
A really nice solution is to use “autoversioning”: a view helper function is passed the file path and returns .. which mod_rewrite then serves as . but the browser sees as a new file only if it’s been updated.
So, for example, “application.css” becomes “application.1234567889.css” where 123456789 is the unix timestamp of the last time it was altered.
In PHP a function such as this works:
public function autoVersion($uri)
{
$parts = parse_url($uri);
$root = getcwd();
$mtime = filemtime($root.$parts[‘path’]);
return preg_replace(“/(\.[a-z0-9]+)(\?*.*)$/”, ‘.’.$mtime.’$1$2′, $uri);
}
In your virtual host config or .htaccess file include this to do the path translation:
RewriteRule ^(.+)\.(.+[0-9])\.(js|css|swf|xml|jpg)$ $1.$3
And that’s it: hands-free version updates.
Edit: the first para got stripped. It should read
a view helper function is passed the file path and returns filename.timestamp.extension which mod_rewrite then serves as filename.extension but the browser sees as a new file only if it’s been updated.
The latest jQuery version is 1.4.4, I would use that instead of 1.4.2.
Good point. I updated it, and I also added a comment to indicate that the jQuery version might be out of date, because I obviously won’t be updating my version every time jQuery does. Thanks for the note.
You don’t need to include html5shiv, because modernizr fixes that for you (creates new html5 elements) and much much more.
I do like this template, but I wouldn’t include conditional comments. I would only choose to support the latest browser. It is a matter of principle.
Yeah, I included a note in the comments (in both the commented version and the stripped version) telling the user to delete the shiv script if they use Modernizr.
Also, I agree with your principle, but clients probably don’t! :)
Two issues with the jQuery file you call.
First, and most importantly, you’re calling the full version with comments and all. You need to call the minified version (jquery.min.js instead of jquery.js). The executed code remains the same but the file size is much smaller.
Then you could use a URL that calls the most recent version of jQuery autmatically. For the latest in the 1.4.x series, use https://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js, and for the latest in the 1.x series, use https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js.
Right now, they both map to jQuery 1.4.4. In the future they may map to, say, jQuery 1.4.7 and jQuery 1.6.1. Targeting the latest 1.4.x release for current developments is more reasonable, since new series (1.5.x, 1.6….) may introduce API changes and break code developed against 1.4.x.
Florent,
You’re correct about the minified version, so I will change that.
But regarding the versioning, that’s not the best choice, and it’s strongly discouraged. Paul Irish’s Boilerplate doesn’t do that, so I asked him about what you said. He says there WILL be breaking changes even within a 1.4.x release. But mostly it’s for the caching. If you use the “1.4” reference or the “1” reference, you get zero cache benefit. See:
http://encosia.com/2010/09/15/6953-reasons-why-i-still-let-google-host-jquery-for-me/
http://paulirish.com/2009/caching-and-googles-ajax-libraries-api/
And keep in mind that Paul is on the jQuery team, so I would go with his advice on this.
i foud it quite usefull to target ie7 and ie8 – saved a lot of time when working on css3 simulation for those two
the “http:” part can be omitted, to make it safe for https use ( ie will not throw those annoying alerts ) ( i’d give the credit to someone who came up with this solution, but can’t remember – sorry :( )
so it’d go like
other than this – really neat template ;-)
http://paulirish.com/2010/the-protocol-relative-url/
Yes, as the above comment points out, it was Paul Irish (unless he got it from someone else).
I discussed this with him and I had a problem with it because when you use that URL for a local file, it basically hangs the browser’s load bar, taking too long to actually load the file. Paul confirmed that yes the “file://” protocol is very slow in that instance, so it can be annoying, so you have to change it for local.
I just felt that since mostly less-experience ones would be using mine, that the possibility they will be able to figure out why that’s happening would be slim, so why annoy them.
I suppose if you’re working with PHP or something, you could just plug in a variable that changes the URL based on local vs. remote, so that would be an acceptable solution, because yes it is a good thing to add to avoid that IE security alert.
well, You can always comment out CDN link for development and use local file ;-)
ps
i’ve noticed your fix for long code ;-)
Yeah, to have blocks of code you have to use “pre” and “code” tags, nested, otherwise it gets all wonky. Inline code just requires “code” tags. (which is mentioned in the instructions, but nobody really reads that anyhow!)
well, i used <code> ;-)
oh, now i got it ;-)
the instruction seemed somehow tricky…
I’ve got a question about your template: at the comments you say “Each section should begin with a new h1 (not h2), and optionally a header” (at section#main header), while I’ve always learned that a document can only have one H1 (document title).
Is there a reason for this or some little research? Because if I search the internet nobody is giving this advice.
Besides the question, I think this is a perfect start to build HTML5 templates without all the stuff of Boilerplate (although it has some very usefull features).
each article / section can have their H1s respectively and they “contain it” without any conflicts ( but remember that deeper You nest it, the “lower” priority it gets )
Yeah, that’s a change from the stuff we’ve done in the past. Not to say that the old way is incorrect. It’s still valid HTML5; HTML5 is backwards-compatible, so that’s still good.
The difference now is the way we’re encouraged to structure documents with “section” and “article” tags (as the above comment mentions).
You should read this article I wrote on Smashing Mag:
http://www.smashingmagazine.com/2010/11/10/learning-to-love-html5/
There are a number of things discussed about new “best practices” when using HTML5, and specifically I discuss the H1/H2 thing under the subheading “Headings Down a Different Path”.
You should also read this article by Bruce and Remy:
http://www.smashingmagazine.com/2010/09/23/html5-the-facts-and-the-myths/
I never did agree with the HTML5 Boilerplate idea, too complex for being able to do something simple. Something like http://switchtohtml5.com is something that is more of a ‘template’. I welcome you to review it :) Something which is easy to use, you click a few boxes and get a framework. I still need to code in support for ID’s, classes and CSS generation, but I am happy with it so far..
That’s pretty sweet, Mikey.
And it reminded me that I didn’t use the “nav” element in mine… Hmm… maybe I’ll add that. Thanks.
Hello,
nice and simple template!
But I’m not sure, if your use of the section element is the best way. Remember section is not for styling purposes (W3C) so maybe a simple div would be the better choice…
I still have not fully understood how’s the correct use of section and article.
Maybe someone could enlighten me?
Greetings,
Martin
I think the section tag should remain, but instead the article should be wrapped in an article tag. Therefore, section would refer to the primary content area that would house multiple article tags.
You talk above about the <section> tags and are thinking about removing them. I would probably leave them since they are there to define page structure, i.e. you have a header area, a content area and a footer area for the page. It’s perfectly valid to use a section tag for that content area. It sort of replaces div tags with that regard.
What I see missing is the <article> tag. Your content should be inside an article tag. Each article can have its own header, h1 (hgroup if necessary), footer and sidebar.
One last point, you mention in the comments for loading the style sheet that the type (I think) is no longer required. True, but it doesn’t hurt to specify it. HTML5 allows a lot of sloppy behavior back into our code that xhtml taught us to get rid of, like quotes not being required around attribute values, or tags being in mixed case. You can still use the xhtml style rules with HTML5 and at the end of the day produce clean readable code. There are a lot of browsers out there that are not HTML5 savvy and while we can wedge the new tags in to the IE’s, we still need to write solid code that would validate in HTML4 to avoid browser problems.
Yes, I might incorporate an “article” element, but most of the content I included is just dummy example content anyhow. In most cases, people will be just ripping it out and starting from scratch.
To be honest, I think it would be good to use the “article” element in a secondary way. Although it can wrap an actual article (i.e. blog post), it’s not supposed to refer to that kind of article. It technically refers to “article” as in the phrase “article of clothing”. See this post by Bruce Lawson:
http://www.brucelawson.co.uk/2010/on-html5-article-element/
And yes, HTML5 allows sloppy coding, but that’s because validation is now separated from “linting”. See my comparision in this article:
http://www.impressivewebs.com/understanding-html5-validation/
And HTML5 is backwards-compatible, meaning that leaving off the “type” attribute for the “link” and “script” elements will not affect the page, no matter what browser is being used. We have to realize that those involved in producing the spec for HTML5 have carefully examined how older browsers treat markup, to ensure that HTML5 doesn’t “break” the web. So, my advice is: If you’re using the new doctype, don’t use the “type” attribute, because it’s redundant and unnecessary and its omission will not cause any problems in any in-use browser.
Funny and sad that even with html5 we still need a ‘reset’.
Right now html5 only practical value is as topic for blogging.
Good developers don’t need a reset; they prefer it.
And I don’t agree that HTML5 isn’t practical. Oprah’s website uses it:
http://www.oprah.com/own
(roll over the 3 big images, HTML5 video is used).
With all the fallback options and polyfills available, there’s no excuse to not start using it in new projects. True, those polyfills can be annoying, are maintenance nightmares, and are poor in performance, but that’s just a growing pain while we look ahead to better days.
Ideal? Not even close. But it’s the best we’ve got right now.
I like what you’ve got here. Nice work!
One thing I noticed, your comment above the <nav> section reads as follows:
Main nav, styled by targeting “#header nav”; you can have more than one nav element per page
However, there’s no header ID, so this should actually be targeted as “header nav”.
Brad, good catch, I’ve fixed that note.
But actually, there is an ID on the header element (the first one), “#hd1”, which is there for that purpose, to target stuff inside the header. If there’s more than one header with a nav inside it, using “header nav” or “header>nav” won’t be specific enough, so the note now uses “#hd1 nav”.
Thanks for spotting that.
“Also updated jQuery version to 2.4.4” futuristic!
Haha… yeah, I’m waaaay ahead of the game!
Thanks for spotting that, corrected.
this is good, very useful guys
The Analytics code should be placed before the page content if you want to track pdf downloads etc. Google recommends it to go right after the
<body>tag.Wow, that didn’t land in the right location. Sorry.
Nice. Needed. Bookmarked.
If reset is a fundamental thing that good designers do, why doesn’t the W3 just make it part of the standard. Maybe something like:
body {reset: all}Simple. Clean. It doesn’t have to be reinvented over and over. Saves a few download bytes :-)
I don’t think that would be good enough, though, because the resets do more than just “padding: 0; margin: 0”. And not everyone agrees as to what should be included or done in a reset, so I think if the browsers did that as a standard, then it would just incite people to create a new “unreset” or something similar.
Just to muddy the water a little bit, I too created an HTML5 template, one designed with smartphones in mind. foneFrame is released under Creative Commons (CC BY 3.0): http://foneFrame.com/fF/
A minor detail:
http://stackoverflow.com/questions/7020961/uppercase-or-lowercase-doctype
Why dont you use :
<script src="http://code.jquery.com/jquery-latest.js">instead upgrading jQuery all the time.
Because it’s bad practice to include that in any website. If you build a site using jQuery 1.7.2, and use that URL in the site’s files, you could break the site later on if something from 1.7.2 is no longer available in (for example) 1.8 or 1.9.
You should always use a specific point version, and never a link that just points to the latest.
Is HTML5 reset out of date now? Last ‘Milestones / Changes (v2)’ update is 2011.04.13; and it uses modernizr 1.7, when last version of modernizr is 2.6.2.
I don’t think a template like that can go out of date, necessarily. And the libraries included in it will always be out of date. You just need to update it with your own versions. Also, Modernizr nowadays is best if you build your own custom version, based on what you want to use. See:
http://modernizr.com/download/
So it shoud be fine to use, or you can try out mine or HTML5 Boilerplate.
Thank you Louis.
thank alot !
Newbie. I’m having trouble to get this in Dreamweaver.
I used your pg source and dloaded the files.
Could this be a more simple template without all the js?
For instance the header with everything in it and the rest can be added
By the way it’s the most beautiful I”ve seen
I don’t use Dreamweaver, so I can’t help you much. But if you’re having any trouble, just open the code view in Dreamweaver and copy and paste the code from mine, rather than opening my files. Maybe that will yield better results.
I’m loading it fine in Dreamweaver and Html Pad, the only 2 editors I have.
Comp new this year and so is W8 and Explorer 10.
It loads fine in all 3 major browsers, by using your vie2w source code.
Would like to adjust font size in header -navbar section to a smaller font.
Thanks for it. Be a while before I use it on my site as I am new to html 5.
AL Lyman