2013: the year we stop using PSDs

Today I’m deep into preparing my slides for the HTML5 Developer Conference. Topic: “Making Peace with Twitter Bootstrap.” I have forty-odd minutes to soothe everybody’s ills with this ubiquitous framework. Since it’s a developer’s conference, I’ll emphasize solutions for people like you and I: front-endy things about SASS and Bower and whatnot. This will be the reasonable-sounding part of the presentation. Then, in real time, I’ll fight the temptation to disintegrate into full-on rant mode.

Here’s what I’ll try to say with terse, politely worded slides, rather than foaming at the mouth:

No more PSDs.

Stop it with the goddamn PSDs already. Fer Chrissakes, it’s the year 2013. High time to stop pretending to simulate Web applications with twenty-three-year-old image editing software.

Okay, so you’re a visual type, and you like to sketch your ideas in Photoshop? Fine. But for the same reason you don’t hand a page torn out of your Moleskine to your developer, you shouldn’t hand her a freakin’ PSD either: both formats communicate very little about what you intend for the application interface.

As Mule Design Studio puts it,

A PSD is a painting of a website.

If your interface links to framework stylesheets, and your application’s stylesheet bristles with !important rules overriding those styles, it’s a definite sign your project isn’t using the framework’s styles effectively. There are a couple of sources for this problem: 1) a developer not understanding how to use CSS selector specificity to create new styles; and 2) a design completely, totally detached from what the framework offers.

Want to drive Web developers insane really fast? Require them to cram Twitter Bootstrap, ZURB Foundation, or pretty much any CSS framework into a design dictated by PSD. In this workflow the designers and developers never discussed nor established viewport breakpoints, element widths, line heights, and such ahead of the design and development process, and fashioning something resembling the Photoshop comp out of pre-built components becomes an exercise in crazy-making CSS stunts. Meanwhile, the really necessary work of creating responsive design goes undone–what really happens is more like Reactive Design, when somebody glimpses how awful the interface looks like on somebody’s phablet, and then there’s a mad scramble fifteen minutes before the client meeting to patch over the rough spots hoping nobody notices.

My freelance rate is by the hour, and this kind of unanticipated rush developing can be lucrative. But it enrages me instead, because it’s entirely unnecessary. These days a Web design is properly devised in markup and CSS. Don’t like the associated learning curve to do this by hand*? Then use any of the following alternatives to Photoshop:

  1. Adobe Edge Reflow. Even Adobe wants you to stop delivering paintings of Web sites.

  2. Easel. Design for the browser–in the browser!

  3. Jetstrap. Get rid of that whingeing front-end developer and make the interface yourself.

Why are you still designing Web applications in Photoshop?

* A link to a design blog post from over three years ago.

The latest in HTML

No question, HTML5 is big news. It’s the subject of sold-out conferences, mobbed Meetups, and recent best-sellers. It’s even become a catch-all marketing phrase perfectly contoured to shove into presentation slides. But HTML5 better watch its back. There’s yet another promising HTML standard out there. It’s what you’ll want to use on your next project–hip, cool, and wholly cross-browser compatible.

Get ready; here comes HTML 3.2!

Whether you’re looking for a new front-end dev gig, or just trying to freshen up your skills, learning HTML 3.2 in the upcoming months will be crucial. Fortunately, it will probably be a skill you’ll enjoy using once acquired.

When you convert your legacy markup from HTML5 to HTML 3.2, you’ll find some elements familiar to you: <P> and <BODY>, for instance. The biggest task you’ll have is removing all that CSS cruft so you can take advantage of HTML 3.2’s many presentational tags and attributes, such as <FONT> and <CENTER>. You can also replace many lines of CSS rules by using <TABLE>, <TR>, and <TD> for layout (a technique possible in HTML5 as well, but rarely explored).

Other features of HTML 3.2 include the useful <BLINK> and <MARQUEE> tags, though, regrettably, these have poor cross-browser support. You will have to polyfill with JavaScript to assure that all users can access this content.

Attendance at the recent HTML 3.2 Hackathon was small but enthusiatic

If your legacy HTML5 code base is extensive, you might find the job of converting it all by hand a daunting challenge. This is a situation ready-made for a WYSIWYG editor. Software makers have taken notice of the opportunity to jump on the HTML 3.2 bandwagon; you’ll have your pick of user-friendly tools. The most popular choice seems to be Microsoft’s FrontPage. Adobe isn’t far behind with the PageMill application. If you have the Netscape browser installed, you’ll find its built-in Composer product easy to use for your cutting-edge HTML 3.2 project.

True, it can be frustrating sometimes to keep current. Just when you thought you knew the difference between <article> and <section>, along comes an HTML standard which includes neither. Yet think of the compensations–you’re not losing <canvas>, you’re gaining <LAYER>.

Why we’ll stop using ID in our stylesheets

Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.

It didn’t repay them.

“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?

Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?

I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?

I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?

Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.

Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.

But why has the ID selector fallen into disfavor?

Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.

Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.

What not driving for 25 years taught me about UX

One drizzly morning in 1988 I arrived at the infamous

San Francisco DMV office
.

There were two lines for service, one noticeably shorter than the other, and since I was already running late for work, I stepped into that shorter line. At my turn at the counter, I completed the paperwork for a state identification card instead of a driver’s license, which didn’t seem that important to me at the time, since it’d been already two years since I last drove a car, and now I lived in SF, which had

passable public transit
. It wasn’t this grand activist moment for me, this kind of Damascus Road flash of insight–no, it was just my deciding that driving wasn’t very important to me.

And I was right.


Not


driving proved more important.

Try getting around the United States without a motor vehicle.

Asphalt Nation, by Jane Holtz Kay
Asphalt Nation, by Jane Holtz Kay
Try it for a while. Try it while also attempting to sustain a career, relationships, household, your sanity. You will learn, as I did, very important lessons about how user experience can be structured to assist or thwart your journey.


Here are some of my discoveries:

Places with more than one way to access them have greater vitality.

As Jane Jacobs pointed out, small city blocks encourage

walking

and transit use. Places which permit access only by motor vehicle are dead-feeling and often

moribund
, which is why a high

WalkScore

is becoming so attractive to potential buyers.

In Web terms, how many of us enjoy visits to sites which permit access only through needless Flash intros or

mandatory registration
? These pages act like those guard kiosks in suburban gated communities. Or how about the sites with no provision for usage by mobile devices?

No, I am

not

going to watch your pointless branding animation, nor wait for your bloated JavaScript form validation script to load: I’m going to shop at your competitor’s site.

You can’t “set it and forget it.”

All over the United States, roads and transit systems are crumbling into unusability because of deferred maintenance. The jagged potholes in my neighborhood act as the speed bumps the City of Oakland can’t commit to installing in this dire period for municipal budgets. A couple blocks away, the once-handy AC Transit bus system runs fewer and fewer buses, thanks to

neverending budget cuts
. Being stranded for 45 minutes waiting for the next bus after missing one by just seconds is a pretty common experience for us commuters.

Out there on the Web are so many undermaintained, tatty sites that I really don’t need to

link

to them. Outdated copyright date on the footer? “Best viewed in Netscape” graphic? Visual design so old it’s on the cusp of being retro-cool? Those are easy to remedy–if you commit time and money to fixing them.

Accessibility is pricey to build in…and exorbitant to bolt on later.

When the

Americans with Disabilities Act

passed in 1990, there was the usual unappealing backlash of nay-sayers claiming that the Act’s provisions were merely nice-to-have and too expensive to require. Despite that, the built environment of the United States changed rapidly to include curb cuts, ramps, and wheelchair-accessible bathrooms. Building owners whimpered about the expense of retrofitting for ADA-compliance; new construction posed the advantage of having these features built in from the start.

The question of Web accessibility arose pretty early in the

medium’s history
, but remains incompletely answered. Too many site owners consider accessibility a “nice-to-have, but…”, or something at which you can toss a few inadequate

“alt tags”

and be done with it, whereas true accessibility requires

assessing

how your application or site is used in different situations: can this site be used without a keyboard? Without a monitor? Without color contrast?

Making something accessible also makes it relevant to use cases we can’t anticipate. When I injured my knee in 1992, I sure appreciated those buildings with elevators and ramps. When I started browsing the Web on my Palm Treo in 2005, I admired those sites with text-heavy, low-graphics means of interacting with them.

You’re free to think you don’t need to accommodate a diversity of users, of course, just as you’re free to require a motor vehicle to access your physical location. And you’re free to destroy your own brand with slipshod UX. It’s a free world.

HTML5 Boilerplate Rolls Into Town

Standing room only, and a waiting list besides–what was the attraction bringing so many to the tech college conference room at Fisherman’s Wharf?

Haloed at one end of the room by the glaring video lamp, a man, a laptop, and the new way you should build the front-end of your Web app. Ladies and gentlemen, presenting Paul Irish, in turn presenting the HTML5 Boilerplate.

There’s much you can gain just downloading it, of course. You could opt to pick through the unzipped goodies and apply them piecemeal to your aging markup, refinishing your early 21st-century XHTML with some latter-day varnish. But there’s a lot more in the Boilerplate than too-hasty reading of the docs will reveal.

Irish, one of the mod squad behind the informative and massively entertaining YayQuery podcast, delivered a quick, focused survey of the Boilerplate’s many benefits to those eager to follow advice like Steve Souders’s 14+ rules. Among these is a customized .htaccess file, for those of us with good intentions of, say, gzip’ping assets but only rudimentary Apache admin skills–that’s worth the attention of a full room all by itself. Another is the built-in provision of QUnit: no more chasing this down to install separately. And coming along in the bright future is the Boilerplate for mobile.

Build an ant!?

But best of all is the build script. No wonder Irish calls it his favorite part of the Boilerplate.

Here’s where mere mortal front-end devs can finally scale the Olympus of best practices. Need to combine your CSS files? Your JavaScript? Optimize, minify, them? Remove test suite leavings? Excise all those dangerous calls to console.log? Boilerplate’s build script does this for you. Hurrah; I didn’t need yet another checklist to consult.

I was gratified to hear someone take HTML seriously. For too long writing markup‘s been dismissed as a simple, easily acquired technique that any drooling idiot can/should perform. Now there are Meetups full of software engineers anxious to learn things like table-less layout. Hah! Isn’t the Web fun?

What not to buy in 2011

This is the time of year when the Interwebs are flooded with “what to buy…” consumer guides. In contrast, the things I discuss below are much cheaper, saving you both time and money, because in the end you won’t be shopping for them at all.

(An aside to Web services freelancers: you know, if we stop offering these things, people will stop thinking they can obtain them. Give it a thought.)

What not to buy in 2011

  • Support for IE 6. Freelancers–put a clause in your contracts that requires a $10,000 deposit before you even start up IETester or the like.
  • Meetings requiring developer attendance.
    "Sunday," © Peter Paul Jacques
    Described variously as “toxic,” “a disaster,” and “the biggest productivity killers for programmers,” meetings are relics from the twentieth century which have as much relevance to your technology projects as do carbon paper and stenography.
  • The cost of a stern “butts-in-chairs” policy. Savvy, experienced developers know what conditions make them productive, and these are various. Nobody lists compulsory enclosure in a cube farm among those conditions.
  • Huge office spaces. Since you’re not having meetings, and you’re letting your team co-work or telecommute, you don’t need all that much space anymore.
  • Fake work.
    Fake Work: Why People Are Working Harder than Ever but Accomplishing Less, and How to Fix the Problem

    This should be obvious, but somebody had to write a whole book about it to expose the problem.

  • Expensive conference fees. As Rebecca Murphey noted, the most useful conferences for Web technology seem to be ones organized by and for practitioners, who aren’t always bankrolled by deep-pocketed corporations.
  • Tag soup, nouvelle cuisine style. Regrettably, HTML5 provides just as many opportunities for lousy markup (“<div>-itis,” overuse of class and ID attributes) to the novice and/or the unconcerned, as  did earlier HTML standards.

What’s dropped off your 2011 shopping list?

HTML5 Forms: browsers get jetpacks

Self-identified standardista Estelle Weyl enlivened a recent HTML5 Meetup with her summary of the neat stuff we could use if only everybody used, say, the latest version of Opera.

How many lines of JavaScript have you written to enforce a pattern on user input? To set focus on a certain form element? To mark input required, and bark at the user who doesn’t supply it? How about offering a calendar pop-up for a date picker? Between HTML5 and CSS3, there are new options for markup–no scripting necessary!–which handle these scenarios.

Well, that’s the promise, anyway. It’s nice to hear the future is nigh; it somewhat offsets the discouragement you’ll feel when you obtain the latest statistics on how many Web users continue to use terrible software such as Internet Explorer.


Carefree living post-IE 6

Hearing about nifty HTML5 wonders at present feels a lot like watching those filmstrips about “life in the year 2000 A.D.!” when I was a kid: substitute attributes like “placeholder” and “datetime-local” for “flying cars” and “robot servants” to update to the latest shiny, optimistic vision.

Yet it’s not we shouldn’t use HTML5 forms–we’ll just have to prop them up with JavaScript crutches, until the browsers of Tomorrowland are in common usage.

Note: Estelle’s presentation might be expanded for SXSW 2011.

How to demoralize your front-end developers

Stop failing at this apparently necessary chore; I’m here to help.  I can verify that all the following techniques have worked on for me.

How to Demoralize Your Front-end Developers

  1. Constantly change requirements. It’s, what, the day before the scheduled launch?  And the product doesn’t include that absolutely requisite feature you didn’t think to require until now?  Well, shoot, just demand it!  And make drastic changes to the visual and interaction design as well–where’s the glory in completion?
  2. Constantly change the visual design. You took that one-day course in CSS and remember only that it was a way you could change all of a site’s visual elements from one file.  Okay, then, let’s start by making all the blue things red, and all the red things green–but only on Tuesday–wait, change them back again, make the old red things red again–and oh, all the gray things white and the white things gray, and the grayish-white things brown, on alternate weekdays.  And all the wide things “smaller” and the narrow things “a little bigger” and the tall things “a smidge shorter” and… just marvel  how enthusiastic your front-end dev grows.
  3. Give them a lousy setup. Cram your developers into a spot at an unergonomic table in between the gal who has the obnoxious sound themes enabled on her workstation and the guy who spends his entire work day shouting into a speaker phone. Don’t let your devs use their preferred operating systems or software–point out that you’ve generously provided work computers exactly like your own, with that reliable ten-year-old OS and the proprietary groupware that cost you a bundle.
  4. Decide midway that you need pixel-perfection in IE 6 after all. So you visited your hermit, anti-consumerist brother-in-law living in a shanty with a hand-me-down Gateway 2000 accessing the Web over intermittent dial-up, and you looked like a putz because your beta site didn’t render perfectly in Internet Explorer 6.  Well, crack the whip so he can enjoy those rounded corners, PNGs with alpha transparency, and painstakingly mitered grid layouts.
  5. Critique the browser rendering against one in a different medium. Different media, you say?  Hardware?  Pshaw!  Do as I’ve actually witnessed:  hold a paper print-out of the intended design up to the monitor, and compare the rendered page unfavorably to the PDF print-out.  Remark on the differences in proportion and color.  Watch your devs writhe in either agony or amusement at your request to make the two formats identical.
  6. Assign visual design tasks to your developers. Get rid of that pesky professional, and go with a leaner team equipped with mere adequacy in Web design.  Start with vague instructions to your front-end devs (“This area of the page needs to really say ‘breathy,’ but not ‘vaporous'”), and end with your looming over them, jabbing at the display of a competitor’s site on a monitor, and shouting, “See? See?!  Like this–only different!”
  7. Pit your developers against each other. Break up that predictable day with a bout of office politics as bloody as any combat in the Colosseum!  Let one developer bully another, favor the least productive developer over the others, and disclose important project details only to the dev most likely to hoard the information.  When one dev leaves at 6pm to tend to the rest of his life, assign all his duties to the other one still in the office. Whatever you do, don’t let these people end up liking each other.
  8. Constantly interrupt with phone calls, e-mails, IMs, or in-person meetings. You know, if you give your developers the chance to concentrate, to get into the flow of working, there’s no end of disaster which could happen:  they might  finish the tasks you’ve assigned to them, or write bug-free scripts, or finish a work day with a sense of accomplishment.  Then you’d all miss an important feature of the Development Drama:  the climactic battle in which each side slays the other in murderous frenzy.
  9. Ridicule their professional opinions. Don’t listen to the nay-sayers when you describe that pop-up with autoplay Flash, animated GIFs, and blinking text you’re confident will add loads of appeal to the application.  Show them your teenaged son’s MySpace page and pointedly ask why they can’t make something like that if he can.
  10. Don’t use a bug tracking system. Sheesh, you already send all those e-mails.  Why repeat yourself in some persnickety little data entry form with those dropdown things which force you to prioritize the issue?  Just repeat: everything’s critical and of highest priority.  See, easy to remember.

Hmmm, something’s missing.  What have I left out?

My First Web Page

Some digging in a dusty file box the other day yielded no fewer than three floppy disks. What wisdom might these ancient tablets convey? Fortunately, there was at least one device in the house which still had a floppy drive. Result: mostly disappointment. The files were either first drafts of things I’d sent off to magazine editors in the late 1990s, or grouchy letters to my landlords of the same era. However, there was, archived with apparent pride, my first effort as a Web developer.

Step into the WABAC Machine. The year is 1997. I was the admin assistant for a team of software engineers. I was also something of a mascot; if the guys (yup, all guys, except for me) had a noncritical technical task they thought I could handle with a little instruction, they threw it to me, because I guess I looked really grateful to be doing something besides ordering lunch and taking the abusive phone calls of the company CEO. The most enduring instructions they gave me was how to use FTP, IrfanView, and NotePad to develop the team Web site. Of course, these tools seemed insufficient once I made a few changes–I wanted colors! Silly typefaces! Dizzying background images! And HTML seemed so hard to learn…

I remember downloading a lot of trial versions of the trendy WYSIWYG software of the time: an early version of Frontpage (which had me puzzling over these things called “stylesheets”), Adobe PageMill, and the editor which came with Netscape Gold. The one I used the most seemed to be NetObjects Fusion, which I notice is still available. It was a big, handholding, friendly giant of a program; it set everything into tables and FONT tags, and we were buddies. I felt masterful.

Nobody I worked with was a Web professional–no designers, no information architects, no UI devs. Creating Killer Web Sites had only just been published, Web Pages That Suck was treated mostly as a humorous diversion, and even Jakob Nielsen was as yet rather obscure to the average person making a Web page. It was in this Wild West environment that I devised this:
My First Web Page

I’ll enhance that retro atmosphere with a sample of its markup:

<HTML>
<HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
   <META HTTP-EQUIV="Page-Enter" CONTENT="revealTrans(Duration=1,Transition=6)">
   <TITLE>ES Home Page</TITLE>
</HEAD>
<BODY BACKGROUND="amoeba.jpg">

<CENTER>
<H1>
<FONT FACE="Wide Latin"><FONT SIZE=+4>Engineering Services</FONT></FONT></H1></CENTER>

<CENTER><IMG SRC="grey_dots.gif" ALT="grey_dots.gif (6699 bytes)" HEIGHT=47 WIDTH=890></CENTER>

<CENTER><FONT FACE="HELVETICA"> </FONT></CENTER>

<UL>
<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">ES
Quote Status</A></FONT></FONT></LI>

<LI>
<FONT FACE="HELVETICA"><FONT SIZE=+2><A HREF="[...]">Current
ES Status Report</A></FONT></FONT></LI>

Yeah, go on. Snort, carp, whatever. But this is how we did things then, back when browsers “innovated” with crap like BLINK and MARQUEE. A year later I was back to using text editors–haven’t touched a WYSIWYG since. Just a year later I was using CSS and disdaining FONT, and a year after that I was riding the dot-com boom as it crested. So it’s worth examining your old work product, if only to swell with pride over how far you’ve come since then.

What was your first Web page like?

A visit with HTML 5

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>
</menu>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5’s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.