HTML5, again

Aaron Mentele — Wed, 17 Mar 2010 21:49:03 +0000

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

. This is a

. 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. Sexy.

Declaring your character set just got simpler, too.

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:




  
    Boom
    
  
  
  
    
      BOOM
      I'm using HTML5!
    
  
  
    
      a link
      a link
    
  
  
    
      
        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.
      
    
    
      Archives
      
        Sooper interesting story.
        Very interesting story.
      
    
  
  
    No rights reserved.

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.,

) 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:

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.

Aaron Mentele, Charisma 18 » html5 css3

HTML5, again