Nov 17, 2010
Building a bulletproof HTML5 framework
One tool every front-end developer should be using is a solid template or framework for new projects. "Frameworks" in general have gotten a bad reputation for being bloated with unnecessary code and classes just to save a few minutes. I don't use any layout or CSS frameworks precisely for those reasons. However, creating an HTML framework that is customized to your own coding style and tastes, while leveraging the latest technologies is definitely worth considering.
The goal of a framework is to set a foundation for new projects so you can hit the ground running. It should include elements and styles that you use for most projects, but the key is to not waste any lines of code. As a general rule, I only include code in my framework if I use it in 80-90% of my projects. If not, I cut it out to make sure I'm not wasting valuable kilobytes.
There are currently two open source HTML5 frameworks: HTML5 Boilerplate and HTML5 Reset. I think both are very solid and worth checking out when you create or update your framework. The problem is that I don't believe there is a "one size fits all" solution for this stuff. Every developer has their own style and preferences, so in the end you should build a framework that suits you. Hopefully this article will give you a good foundation of resources, code and advice to get going.
Can we use HTML5 yet?
Whether to use HTML5 or not should be assessed on a case-by-case basis. I'm using it in client projects unless over 2% of the visitors have javascript disabled, which means I am using it in almost all new projects. HTML5 is already very well supported by modern browsers and it is simple to bring old ones up to date with a small amount of javascript. Richard Clark and Remy Sharp put together a really good article summarizing the positives and negatives of HTML5 on HTML5doctor.com, called "How to use HTML5 in your client work right now". It's a very good read.
While CSS3 is a bit more complex with regards to browser support and new syntax, HTML5 is straightforward and easier to pick up. Adding HTML5 support to your project involves one line of CSS:
section, article, header, footer, nav, aside, hgroup { display:block; }Of course, Internet Explorer isn't exactly what we would call "modern". It requires a 4kb javascript file called html5shiv, created by Remy Sharp. I have seen estimates that put javascript adoption above 99% at this point, so it's safe for most projects to depend on a small javascript file for proper rendering in IE.
If it's learning HTML5 you are hesitant about, fear not! Anyone that has a good understanding of HTML4 should be able to pickup the new HTML5 elements in 2-3 hours. Here are a few resources I used to get up to speed:
- HTML5 for Web Designers by Jeremy Keith - I LOVED this book. It's a great desk reference.
- html5doctor.com - A great all-in-one resource
- HTML5 and the Future of the Web - Another great intro to HTML5 here on Smashing Magazine
Code Cleanup
Whether you choose to use HTML5 elements in your framework/projects or not, much of the code in your framework can be still cleaned up, especially in the <head>. Take a look at how we can clean up the DOCTYPE declaration:
Before:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
After:
<!DOCTYPE html>
The only downside of updating your doctype is that validation is a bit more difficult. The W3C validator now includes "experimental support" for HTML5 ... it's just not full proof yet.
Another nice little change is that the "type=" attribute is no longer necessary. Here are a couple of examples:
Before
<script type="text/javascript" src="js/script.js"></script>
<link type="text/css" rel="stylesheet" media="screen, projection"
href="css/styles.css" />
After
<script src="js/script.js"></script>
<link rel="stylesheet" media="screen, projection" href="css/styles.css">
You can update the DOCTYPE and lose the type attribute now, as all common browsers support these changes (including Internet Explorer 6). View source on the Google home page and you will see that even they are following both of these rules.
Meta Tags
Must-haves
<meta charset="utf-8">
<meta name="description" content="">
<meta http-equiv="X-UA-Compatible" content="IE=8">
The first two lines are straightforward and don't require any explanation. The third line forces "standards mode" in Internet Explorer 8. I find it hilarious and somewhat sad that Microsoft let users choose whether they wanted to render pages properly or not in IE8, but at least we have a way to force standards support.
HTML5 Boilerplate stretches IE a little further and forces support for the very latest IE rendering engine with the following code:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
I'm with Aaron Gustafson and his article, "Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8". He says that using IE=edge is risky. There's no way for us to predict IE's next move and I would prefer it not breaking any of my sites. Still, this is something worth your consideration.
Optional
<meta name="robots" content="index, follow">
<meta name="keywords" content="">
<meta name="author" content="">
<meta name="Copyright" content="(c) 2010. All Rights Reserved.">
<meta name="viewport" content="width=device-width; initial-scale=1.0;
maximum-scale=1.0;">
Keywords: I want to touch on keywords and why they are now an optional meta tag. For search engine optimization purposes, keywords are practically useless because they are far too easy to manipulate. None of the major search engines consider them for this reason. The only reason to include them now is if you have a site search that uses meta keywords to assist with indexing.
Viewport: Apple introduced the viewport meta tag for mobile Safari on iOS devices. Setting the scale at 1.0 prevents the user from zooming or scaling the site, so it should only be used if your site is optimized for mobile devices. However, now that Mobile Firefox (aka Fennec) and Android WebKit support the tag as well, it could get tricky as devices differ in screen resolution. If you are optimizing for mobile, the best practice at this point is to use the tag and test it as thoroughly as possible across different browsers.
There are still many other optional meta tags, but none seem common enough to include in a framework. I found it interesting that HTML5Reset has DC (Dublin Core) meta tags in their framework even though major search engines are not recognizing it yet. I'm not willing to go there yet.
Javascript
Browser Selector
Browser Selector is a very useful 1 kb javascript file I use on some projects, but it's not yet included in any HTML5 frameworks. The script started as an idea by 37signals back in 2006. Within a couple of days there was a working version. Browser Selector adds classes to the <body> tag that define the user's operating system, browser, javascript support and in most cases, browser version. Using the script, you can target users on virtually any specific platform and create styles uniquely for them. I comment this script out by default, but it can come in handy every so often.
When there's only a need to optimize for Internet Explorer, Paul Irish has a nice solution for using conditional comments to isolate different versions without the use of javascript. However, in most cases I prefer browser selector because of how flexible and expansive it is.
Modernizer
Modernizer is a popular 5 kb javascript file that uses some of the same awesomeness that Browser Selector does. Instead of targeting specific platforms though, it detects the platform's level of support for CSS3/HTML5 elements. For instance, if the browser supports border-radius, a class of "borderradius" will be added to the body tag. If it does not, a class of "no-borderradius" is added. This way you can create specific styles for each case.
An added bonus of Modernizr is that it adds support for the new HTML5 elements, thus eliminating the need for html5shiv. For a great tutorial on using Modernizr, check out this A List Apart article.
DD_belatedPNG
There are several scripts and solutions available for adding alpha-transparent PNG support to IE6. I think DD_belatedPNG is by far the best, easiest to implement and most flexible. The compressed file is only 7 kb.
Not every project needs to support alpha-transparent PNGs in IE6, but this is a great solution to have on hand when it is required. When building your framework, this is the kind of script you can comment out by default and activate when necessary. Just be sure to read through the known issues before getting started.
Google Analytics
I know including this script is a bit obvious for analytics users, but I mention it so that your framework has the latest version of the Google asynchronous tracking code. Google says the optimal position for the code is on the bottom of the <head>, after any other scripts have been loaded, so that's where I like to keep it.
Stylesheets
One thing to keep in mind that some HTML/CSS frameworks have forgotten is that each stylesheet is another HTTP connection the browser has to make when loading the page. Don't load five or six stylesheets on every page just because you are a neat freak, because it slows everything down.
One to three stylesheets is enough for most projects. I like to have one stylesheet with default framework styles that are re-used on each project, then one stylesheet with styles that are all specific to the project. Here are some good tips:
Browser Reset
The godfather Eric Meyer gave us Reset CSS in order to put all browsers on a level playing field. More recently Richard Clark gave us the HTML5 Reset Stylesheet. The only thing I don't like about Richard's version is that he goes a little further than doing a browser reset. Adding any colors, borders or text styles should not be included in a reset, but that's just my opinion. Study these two in order to define your own reset styles.
Clear Fix
Another snippet of code that is a great addition to most default stylesheets is the clearfix, which most of you are familiar with using. Simply add the class to any div containing floats to clear them properly. For a more detailed explanation, Position is Everything has a nice article on it. Here is the syntax I use:
.clear { display: inline-block; }
.clear:after, .container:after { content: "."; display: block; height: 0;
clear: both; visibility: hidden; }
* html .clear { height: 1%; }
.clear { display: block; } Default Styles
I found a few different resources to be helpful in creating default styles over the years. The first is Blueprint CSS. Some of the text and form styles in their screen.css file are great, but I don't use anything else because it's too much to include in a framework. The second helpful resource is HTML5 Boilerplate. Some of the styles included in the style.css file are really useful ... kudos to that team. I have tweaked the classes to my liking but, here are a few of my favorites:
.hide { display:none; visibility:hidden; } /* hide from browser & screenreader */
.browserHide { position:absolute !important; clip: rect(1px 1px 1px 1px);
clip: rect(1px, 1px, 1px, 1px); } /* hide from browser, not screenreader */
.inv { visibility: hidden; } /* hide from screenreader, not browser */
h1,h2,h3,h4,h5,h6 { text-rendering: optimizeLegibility; }
html { -webkit-font-smoothing: antialiased; }
.replace { display:block; text-indent:-9000px; overflow:hidden; }
/* for image replacement */My final source of inspiration for default styles is personal experience. I regularly review my default styles, deleting code that is used in less than 80-90% of my projects. It keeps the styles from getting bloated, as page load time is always priority one in my opinion.
Print Styles
Like many people, my first print stylesheet was based off Eric Meyer's 2001 article called, "Going to Print". It serves as a nice introduction, but more recently I started implementing an open source print framework called Hartija. With some minor modifications, those styles have served my projects well for quite a while now.
One unfortunate thing about print stylesheets is that they are loaded whether the media is set as print or not. So in many cases, it's an extra HTTP connection that is not necessary to render the web page. In other words, it wastes precious page load time. I learned a solution on Stoyan Stefanov's blog (in the comments), which has now been implemented as part of HTML5 Boilerplate too. Simply add your print styles to the default stylesheet like so:
@media print { ... styles here ... }By using the media declaration instead of a separate file, the styles don't require another HTTP connection and are still loaded when users print the page.
Other Elements
Favicon and Webclip
<link rel="shortcut icon" href="images/favicon.ico">
<link rel="apple-touch-icon" href="images/webclip.png">
Two must-have links as part of your framework are the favicon and the webclip icon. The favicon is a mainstay, so we won't cover that. Webclip icons are specifically for iOS devices. They appear when someone saves your website to their home screen. The dimensions are now 114x114 thanks to the new high-resolution iPhone4 retina display.
Print Logo
Another strategy I've blogged about before that has not yet made it to the public frameworks is printer-friendly logos. Having the company logo show up on printed pages is a nice wow-factor that most coders seem to ignore.
The company logo is usually a background image on standards-compliant websites, but background images don't show up on printed pages. The solution isn't innovative or sexy, but it works really well.
-
At the top of your wrapper, add the printer-friendly logo as a static image, giving it a unique ID like so:
<img src="images/print-logo.png" alt="Company Name" id="printLogo">
-
In your main stylesheet, make sure to set the following styles:
#print-logo { display:none; visibility:hidden; } -
Now in the print stylesheet or separate print styles, set the following and the logo will print beautifully:
#printLogo { display:block; }
Images Folder
One final strategy that works really well for a framework is organizing your images folder properly. I like the idea of setting up two sub-folders, called "content" and "temp". Any temporary or placeholder images from the mockups should be stored in the temp folder so it can easily be emptied at a later date. Images that are part of the website content should be stored in a separate folder in case the website is ever re-designed. Then you know to keep images in the content directory and all others can be replaced with the new design.
My Framework
It's only fair to do all of this talking about frameworks if I make mine available for download, so you can download it here and use it however you like.
As a whole, my framework does less than what is out there. HTML5 Boilerplate and HTML5Reset both go a little further than I'm willing to, but that's totally fine. For example, they both include jQuery, whereas I'd prefer to include it on a case-by-case basis. HTML5 Boilerplate even includes an .htaccess file, which is very cool, but not for me because those things tend to vary for my projects.
Otherwise there's nothing special about my framework other than the fact that I've created it to suit my style and needs perfectly. That's exactly what I'm encouraging you to do.
HTML5 frameworks can only exist as a result of web developers sharing their ideas and code with others. Each framework is the result of many, many smart people sharing their ideas with the web community. It's up to you to take these great resources, make them your own and eventually contribute cool things to add back to the community as your framework improves.
Finally, it is inevitable that some great resources and ideas have been left out of this article, so I encourage you to contribute what you know in the comments or to an existing framework so that everyone can benefit.
Posted in Code - Join the Discussion
