Here’s a simple example: we want to animate a container open and closed, perhaps as part of an expand/collapse treatment.

.acc-demo-1 {
  height:40px;
  padding:10px;
  transition:0.5s all;
}
.acc-demo-1.hidden {
  height:0px;
  padding:0px 10px;
}

Good enough, you say? Back the train up: most screen readers are still going to read the content of that div when it’s hidden. Setting the height to zero isn’t enough (except in VoiceOver, I think – this could definitely change in the future, though). So how about we just add ‘display:none’ when it’s hidden?

.acc-demo-2 {
  height:40px;
  padding:10px;
  transition:0.5s all;
}
.acc-demo-2.hidden {
  height:0px;
  padding:0px 10px;
  display:none;
}

This kills our transition effect in both directions, since the div is getting yanked in and out of the render tree. Fortunately, the visibility property is animatable, so that will work, but with a caveat: if we immediately transition the visibility when we’re hiding the div, it’ll disappear before we have a chance to see it animate closed. So we need to add a second transition declaration to change the visibility after the animation is done.

.acc-demo-3 {
  height:40px;
  padding:10px;
  transition:0.4s height, 0.4s padding;
}
.acc-demo-3.hidden {
  height:0px;
  padding:0px 10px;
  visibility:hidden;
  -webkit-transition:0.7s height, 0.7s padding, 0s visibility 0.7s;
}

That’s more like it. And as you can see, you can also use this technique to make your transition do different things going in different directions – like changing the speed.

I used to tell people that I browsed the web with Chrome and developed with Firefox/Firebug. But it just occurred to me that I’ve completely abandoned Firebug when it comes to development and debugging.

The Chrome Dev Tools are just too awesome. A year or two ago they were still kind of clumsy for me, but they evolved rapidly and added a ton of features in a short period of time. I only expect it to keep getting better.

The web was supposed to work like this:

You start with carefully and semantically marked-up content. Everybody can consume this: search engines, screen readers, feature phones, text browsers, etc.

Next you layer on the styles. They don’t need to look the same in every browser; you can add cool stuff for newer browsers, and the older ones will never know what they’re missing.

Finally you add some JavaScript for rich functionality and engaging interactions.

This strategy has been guiding our web development practices for quite a while now. Progressive enhancement for the win, right?

Maybe. Something new has been growing the past few years.

Web Apps and Client-side MVC

The difference between a web app and a web site might not be obvious to the average user, but to a web developer, it’s huge. Web apps are definitely in the minority, but they’re growing rapidly, and we now have more JavaScript MVC frameworks out there than you could possibly shake a stick at.

A new application framework called Meteor was recently released, and the first of their core principles neatly sums up what makes a web app different from a web site:

Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.

There’s something pretty compelling about about this kind of approach. It makes richer interactions possible, and if you’re building a sophisticated application it might be the only way to stay scalable.  But it’s a decidedly far cry from progressive enhancement.

What to Do

As usual, there’s never one right answer for every situation. You’ll need to think about who your audience is, how they’ll best accomplish their goals, and where you want to go with it. If you want to build the cutting-edge new hotness, an app will be perfect. If you want a site that works on as many devices as possible, progressive enhancement is probably a better approach.

In any case, front-end development continues to evolve as more coding moves from the back-end to the front. Keeping up with it all is tough, so your best bet is to get out there and start building some COOL STUFF.

I recently discovered that you can skin the Chrome DevTools. So, I naturally had to build a Ruby Blue version.

You can download it here on Github, and this is where you put it:

Mac: ~/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css

PC: \Users\YourUsername\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\Custom.css

It still needs a little love, so please feel free to fork and contribute!

There are a number of WordPress plugins out there which purport to automagically create a touch-optimized version of your site.

“Make your blog look beautiful on tablet web browsers in under 3 minutes.”

“Automatically adds a mobile verion of your site.”

“Automatically transforms your WordPress website into an application-like theme, complete with ajax loading articles and effects when viewed from the most popular mobile web browsing devices.”

“Shows an interface designed for a mobile device when visitors come to your site on a mobile device.”

If you’re using or abusing one of these plugins, it’s time to stop.

I come across these sites from time to time and it’s always a poor experience. They try to fake native app conventions and usually do a poor job of it, while simultaneously making it harder to get to the content, breaking the principal of content first/navigate second.

Some of them (~cough~onswipe) have even made the cardinal mistake of assuming that they know how big my iPad is. So when I visit a blog from inside the Twitter app or an RSS app, which gives me a much smaller viewport, I run into trouble fast.

There’s actually a link at the bottom of the page to switch to the normal site, but I can’t see it or get to it. It assumes I’m using the full-height Safari browser – in which case the link would fit – so scrolling is disabled. Nice. Oh, and what’s up with the black bar on the right?

Articles in full-screen-sized modal windows? Oh yeah. I’m having a real tablet experience now. Sure wish it would let me scroll to the bottom of this article. Let’s try Safari instead.

Because it wouldn’t look like a mobile app if there wasn’t a nav bar with a button in it. But ahh, there’s the link at the bottom I was looking for.

Finally.