If you’re a front-end developer, I want you to do me a favor. I want you to pick a project and mark it up in html5. I’m not going to ask you to code a game experience inside the canvas element or replicate a youtube video player or do anything really, except challenge you to declare semantic information about your content blocks.
This is a <header>. This is a <section>. This is a <footer>. Et cetera.
What I heard at southby any time it came up was that HTML5 wasn’t worth the extra effort. I didn’t hear a single dev concerned with browser compatibility or the possibility of the spec changing. Just effort. And that’s bullshit. You’re changing a doctype and working with a few extra block elements.
I’m going to bonus you out, though, to help convince you to do it. This all comes together and opens up a foundation for certain CSS3 enhancements. You’ve heard of @font-face, right? Yeah, read on.
Switching the doctype
It feels sexy being able to type your doctype by hand. If you aren’t already doing it, try it. <!DOCTYPE html> Sexy.
Declaring your character set just got simpler, too. <meta charset="UTF-8" />
Some of you noticed I closed that tag. I like XHTML. Maybe you don’t. You can do it either way.
Tricking out your blocks
You can tell yourself all you want that your id’s and classnames are already informing people and bots of the content type within, but you’d be kidding yourself. Div’s are for suckers. They provide no semantic information to the untrained audience. You could say the same of html5, except that it really is standard.
For those who haven’t read through the spec, here’s an example skel template:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Boom</title>
<meta charset="UTF-8" />
</head>
<body>
<header id="header">
<hgroup>
<h1>BOOM</h1>
<h2>I'm using HTML5!</h2>
</hgroup>
</header>
<nav>
<ul>
<li><a href="">a link</a></li>
<li><a href="">a link</a></li>
</ul>
</nav>
<section id="content">
<article>
<header>
<h3>Implementing new markup is fun.</h3>
</header>
<p>I can't believe how excited I am right now.</p>
<aside>
<p>Related: I like CSS3 too, but Imma let you finish.</p>
</aside>
<footer>
<p>I don't have a footer. This shouldn't even be here.</p>
</footer>
</article>
<aside id="sidebar">
<h3>Archives</h3>
<ul>
<li><a href="">Sooper interesting story.</a></li>
<li><a href="">Very interesting story.</a></li>
</ul>
</aside>
</section>
<footer id="footer">
<p>No rights reserved.</p>
</footer>
</body>
</html>
Simple. There isn’t much guesswork involved in deciding which elements to use where. I typed that out without grabbing from an existing project just to make sure I can say this: IT DOES NOT TAKE ANY LONGER THAN CODING IN HTML4 OR XHTML.
BTW, maybe you spotted some seemingly redundant id’s up there. (E.g., <header id="header">) I did too, but I like to keep specificity basic, and we’re allowing for multiple uses of the same elements. I also have some carry-over habits from my time with divs, and, like I mentioned above, I’m not asking you to throw out any of your practices. I’m just suggesting you can enhance them.
Browser Compatibility
You’re right to be concerned about browser compatibility. There is a whole gaggle of browsers that won’t recognize these new elements. We need to declare them in our css:
header, nav, article, section, figure, aside, footer { display: block; }
time { display: inline; }
That won’t be enough. Most of you have probably heard of the HTML5 shiv that lets you style these new elements in IE. Ignore it. Go get modernizr instead. Call it:
<script src="/js/modernizr-1.1.min.js"></script>
Done. You’re using HTML5. Your site is also now jacked in Firefox 2 and Opera 1, but we’re all grown-ups here. You’ll also notice some js targeting issues in IE, so you might want to keep using divs for slideshows and the like. But I hate to even mention these things. Issues will be extremely rare.
Bonus! Progressive CSS
This is going to seem like I’m throwing you for a loop, but stick with me — this is the bonus I promised. Now that you’re using Modernizr, you have browser evaluation for CSS3 features already happening. Take a look at (inspect) your html tag. You’ll see classes for something like 24 new properties such as rgba, borderradius, cssgradient, and fontface.
Let’s focus on the last one.
One of the things holding us back from using @font-face was browser (in)consistency. We could add to the font stack, but we couldn’t modify the characteristics if we had to fall back from a narrow font, for instance, to something wider like websafe Helvetica. Now we can.
@font-face {
font-family: 'Snowflake';
src: url('/fonts/SNOWN___.eot');
src: local('Snowflake Normal'), local('SnowflakeNormal'),
url('/fonts/SNOWN___.woff') format('woff'),
url('/fonts/SNOWN___.ttf') format('truetype'),
url('/fonts/SNOWN___.svg#:SnowflakeNormal') format('svg');
}
h1 {
font-family:':SnowflakeNormal', Helvetica, Arial, sans-serif;
font-size:2em;
font-weight:200;/* this is an attempt to bust ClearType rules */
}
.no-fontface h1 {
font-family:Helvetica, Arial, sans-serif;
font-size:1.5em;
}
The .no-fontface class allows us to specify variations to the characteristics we’ve set if the browser in question can’t handle @font-face. I’m looking at you, FF3.
Sorry to drop all that as an offhand bonus. I realize if you haven’t played with @font-face yet this might seem like a bit to digest. But FontSquirrel is going to let you find free fonts as well as help you bundle them up for use. The @font-face code above (basically) comes from FontSquirrel. If you want to read a bit more, I wrote about it here.
Two disclaimers: 1. You’re going to want to get your font into photoshop / fireworks / whatever prior to build. Trying to find a close match after the fact will make your head explode. 2. You’re going to hate Firefox 3. It won’t support @font-face whatever you do, and your visitors’ browser stats might make you question your use. If this bothers you, fall back to Cufón.
Anyway…
I don’t buy HTML5 not being worth any coder’s time. It’s easy to implement, and it’s scary to think that some of the brightest authors are going to wait for the spec to be finalized before they get in to try it out.
We’ve launched six projects using html5 and @font-face now, by the way, and are about to launch six more. I’d love to hear if any of you are using it as well. Maybe you’re doing it way better than I. I’d love to steal your ideas.
31 Responses to “HTML5, again”
Good article, I look forward to trying modernizr.
I’ve been tinkering with HTML5 for little personal things lately but have been hesitant to use it on any client projects yet. You make some great points here and I think you just pushed me over the fence. Thanks for putting this up, Aaron!
Like CSS3, I’ve been tinkering with HTML5 things here an there. I’m not a perfect (or the best, or most knowledgeable) front-end dev by any means, but I think I’m pretty good. I wish that, as a community, we would more often adopt things based on usefulness: does it actually solve a problem? Rather, like you mentioned, I feel like most of my peers wait for “official” things like the solidification of specs, or cross-compatibility with ALL browsers. These are pipe dreams. If a new tool is useful, use it. If it’s not, don’t (or wait until it is). That philosophy has kept me learning for my entire career, and I think it’s also what keeps the web moving forward as an industry.
I was hoping to get beat up on this a bit in the comments. It seems like the reason for not using html is something of a meh reaction.
I’ll take your challenge, Aaron. Until I get confused and give up. :)
hey aaron, where can i find the six projects that you guys made with @font-face? urls? would love to see, what you’ve done against the font flickering problem…
many thanks from germany!
mike
I don’t use html5 yet because of the way firefox 2 (and that version of gecko) handles unrecognized elements. If it didn’t fail so epically, I’d be using it for everything, with the IE js shim of course.
I am really not sure about integrating font-face in a client project.
The fonts look terrible on windows xp and let’s face it, there is still a lots of people on it.
Check your HTTP headers before adding a . If the web server is providing a charset in the Content-Type header, the browser will ignore your META charset declaration. Worse case your documents get rendered using the wrong charset and at a minimum you are needlessly increasing the bloat of your webpage. That a performance issue Zoompf’s free scan detects
http://www.w3.org/TR/html4/charset.html#h-5.2.2
http://dev.w3.org/html5/html4-differences/#character-encoding
@Michael – here are three html5 + @font-face examples you can see:
http://electricpulp.com/
http://redesignourworld.com/
http://world25.org/
two more using html5 – @font-face:
http://bieberfever.com/
http://fusion41.com/
@Angelo – We’re seeing FF2 to be less than 1% of traffic. I’m suspicious in a lot of cases that it’s just us testing. You seeing something different?
@Cedric – have you tried adding font-weight:200; to the element? It forces a rethink on ClearType rules.
@Billy – (looking into it. thanks.)
I agree with moving over to HTML5 by using doctype and a few minor things. But moving to and the like are silly at this point when div id=”blah” works just fine. I think that’s what scares people.
“But moving to and the like” should be:
“But moving to <article> and the like”
I remember back when people were questioning the move to divs and floats, when tables “worked just fine.”
I’ve been testing HTML5 and some CSS3 stuff. Seems pretty good to implement now, on personal projects. For clients projects, i may wait for a while.
Now i’m testing @font-face.
I’m going to try modernizr as well.
Nice article, btw.
@Aaron When I was trying out html5, the stats for gecko 1.8 were significantly higher. It obviously depends on the project, but those stats are encouraging. Hooray!
I do currently use the html5 doctype. I probably still won’t use html5 elements on client projects because you need js to get it to work in IE. The old school in me says “html isn’t broken, and there’s a clear migration path to html5 once IE implements html5, which is looking pretty promising in ie9.”
[...] HTML5, again | Aaron Mentele, Charisma 18aaronmentele.com [...]
@Brian – if your concern is the addition of new elements that effectively do the same thing — particularly the article and aside elements — I shared it prior to using them a bit. Article is one that I rarely use but really like. Aside is one that I actually wish would fork. (I want a sidebar element.) It starts feeling a lot less like tag soup when you realize how informative they are when scanning code.
@Jon – except that felt like a more significant change with a greater reward. (At least it did to me.) I hope the app / mobile opportunities give html5 the necessary draw.
@Angelo – I bet you change your mind prior to IE9. Give it a shot.
[...] HTML5, again | Aaron Mentele, Charisma 18 [...]
@Aaron – I’ve given it a shot, and I like it for personal projects. To me, js should be used to enhance experiences. In this case, it becomes a dependency, which I’m not wholly comfortable with for client work.
For the time being I’m using the html5 element names as a class structure for my documents. This should make it pretty easy to upgrade sites to html5.
I get what you’re saying, Angelo. But I’m pushing for a reason. I want to press a lot further than the new block elements, and we’re going to need to start challenging visitor browser choices to do it.
HTML5 offers a lot more than just a doctype and some new elements.
Browser choice aside, HTML5 sometimes isn’t the most appropriate choice for what I’m building. Sometimes it’s absolutely essential. I’m building something now that could not be done (the same way) with anything but HTML5.
I coded my personal tumblog/rant space ‘The Information Paradox’ over a year ago, and have not looked back. It wasn’t really a question of “Should I?” but more of a “Could I?” and have it function as expected most of the time. The answer seems to be yes.
I love the simplicity of the markup–it’s a whole lot easier to look for an rather than a nested twenty elements deep. My markup has become cleaner, faster and much easier to maintain.
With IE9 touting native support of HTML5, I see no reason to avoid using it, at least in personal projects, with an eye on larger sites going forward. Now if the W3C working group could settle on how to smartly include RDFa (a much better semantic marker than microdata IMHO), we could make real progress not only on the semantic markup front, but the semantic web as a whole.
I would just like to point out:
@font-face – Introduced in Gecko 1.9.1
(Firefox 3.5 / Thunderbird 3 / SeaMonkey 2)
( https://developer.mozilla.org/en/CSS/@font-face )
@Balazs – with Modernizr, you’re able to specify additional characteristics to the next font in the stack. I.e., we’re able to dial in second choice fonts as back-up for browsers lacking @font-face support.
@Aaron – Forgot to mention, but I was just writing that in regards to “… You’re going to hate Firefox 3. It won’t support @font-face whatever you do …”.
From browser stats ( http://www.w3schools.com/browsers/browsers_firefox.asp ) I can see that about 83% of firefox users are 3.5 or above, so capable of enjoying @font-face goodness! :)
Of course it’s good to have a tool like Modernizr for a proper fallback!
I got to know HTML5 and CSS3 when I was working on an iPhone web app for a client last year. Since then, it’s all I’ve used on client sites. Firefox 2 is a really small percentage of traffic these days and using the shim or modernizr you can get IE6 to style up the HTML5-specific tags.
I laughed at the line “Div’s are for suckers.” It’s so freeing to be able to get to elements semantically. Using classes feels kludgy now and using IDs feels like an outright failure!
Nice write up. I just launched a tiny one-pager based on this post and it went very smooth.
Couple of quick questions: Do you have a favorite validation service for html5 that you run through? The ones I found seemed a bit clunky. How big of a buzz-saw do you run into if you try to target the new elements directly instead of using their id’s?
btw – modernizr is wicked.
http://validator.w3.org/ is my favorite and it appears to be validating html5 correctly now. Honestly, I’d given up on it, but I’m glad to see it’s back.
I use element selectors in css. They make resets dramatically more useful, for instance (nav ul {list-style:none;} instead of ul {list-style:none;}).
If you meant targeting with js, then you might run into a separate issue since IE has trouble spotting the new elements in the dom, but that isn’t really an issue of id’s vs. element selectors. And there are ways around the issue.
Agree on modernizr. It’s especially helpful with typography.
My second question came from wondering why you still slap an identical “id” attribute on the new elements? After another read through I noticed why… stupid question.
Love the article Aaron.
Something worth noting is that in HTML5 unlike it’s predecessors, you can use h1 for the first header within a new section (an article constitutes as a new section) rather than using the h3 as you have within the article therefore you can now change your example above to have the article shows as:
Implementing new markup is fun.
I can’t believe how excited I am right now.
Related: I like CSS3 too, but Imma let you finish.
I don’t have a footer. This shouldn’t even be here.
[...] 15. HTML5 Again. [...]