Interview with Paul Irish, HTML5 expert
and community leader

by Dave Klein

When I watched my first presentation by Paul Irish, I was immediately engaged. He not only managed to make a discussion of HTML5 code interesting, but there was something about his personality that made the whole thing fun. Irish is a front-end developer, a Google Chrome developer relations advocate, and a jQuery team member. He speaks HTML5 like it is his native language and was named Developer of the Year at the .net Awards in London last November.

When you add Irish's passion for sharing his knowledge to the mix, it's no surprise that he has emerged as a leader in the front-end development community. He is responsible for some of the most useful and educational HTML5 resources available today — HTML5 Boilerplate, HTML5 Please, and Modernizr.

I recently visited with Irish via Skype to talk more about these projects and his thoughts on HTML5.

Klein: Before we dig into your projects, I have to say that I'm blown away by the amount of work that must go into all of your front-end development community efforts. How do you manage it all?

Irish: I've always tried to set the tone that these are community projects and that anyone who wants to be involved can and should be. Every recent project I've been involved with has been a group effort from a lot of different people. It has been really cool because even if something was originally my idea, the execution was made possible thanks to a lot of contributions from the people in the community. I do what I can to keep the projects moving along, and oftentimes my name gets more of the attention than it deserves. The whole community really deserves a lot of praise.

Klein: Let's break down HTML5 Boilerplate, HTML5 Please, and Modernizr. These are all amazing HTML5 developer resources. What are they, and how do they play together?

Irish: Sure. I'll start with Modernizr. Modernizr is a feature detection library, which detects CSS3 and HTML5 features and provides an API for you to know whether they are present in a browser. It gives you some classes on the HTML tag, such as "canvas" or "no-canvas." Based on that information, you can style your site according to the capabilities of that browser. It gives you a lot of flexibility with the ways you can present the experience, especially when it comes to things like CSS3. Modernizr doesn't actually add support for missing features; it is merely intended to detect whether browser support exists.

Klein: Did you personally start Modernizr?

Irish: No. I initiated HTML5 Boilerplate and HTML5 Please and brought them to life with Divya Manian. Modernizr was originally created by my friend Faruk Ateş. A few months after it launched, I was using it, and I rewrote the entire JavaScript. Since then, I maintain it, and I'm the lead developer.

Klein: Tell us about HTML5 Please.

Irish: HTML5 Please came about because Divya and I heard plenty of developers asking how they can know whether something is ready to use or how they can go about making something like Box Shadows work across all browsers. With HTML5 Please, we decided not to provide a JavaScript library but to focus on recommendations. These recommendations are from people who have done this before and have been deep into HTML5 development, and they advise you on the best practice for dealing with each of these features. It's a community project, so anyone can change the recommendation, assuming that the recommendation gets approved.

Klein: HTML5 Please makes recommendations for prefixes, polyfills, or fallbacks for each HTML5 feature. What are these, and why are they important?

Irish: For every feature, there's probably a good way to implement it. For a simple example, consider the border radius, which gives you rounded corners. The recommendation is that you do not load some big JavaScript file or do some crazy hack to make this work in an older version of Internet Explorer. Some features can just fall back to nothing. People will survive with square corners.

A polyfill is JavaScript that enables some functionality or feature in a browser when it doesn't currently support it. There's an enormous community and ecosystem of polyfills available for nearly every feature in the browser that has come out in the last four years. So now you can load a script to enable new features in older browsers. In many cases, it makes sense to do that, but sometimes it doesn't make sense. HTML5 Please is intended to recommend a good course of action.

Prefixes are a fact of life. They exist to let browsers innovate without breaking the web, but in reality, that doesn't exactly translate to what really happens. Right now, browser vendors are working to revise that system to serve developers better. My recommendation to developers is to use a tool to manage the complexity of prefixes for you, so you don't personally have to type out every possible prefix for every scenario.

Klein: Regarding HTML5 Please, what flags an item as something that needs to be changed? For instance, if something is tagged today as "avoid," how does that recommendation get revised? Is it your decision or a crowd-sourced decision?

Irish: It is a little bit of both I think. We have had this same discussion around WebGL and a few other things. It depends on what the browser support is, what the fallback story is, and whether there are a lot of browser bugs as well as several other things. It involves taking inventory of the entire scene of that particular feature and making a call. Sometimes it's obvious, and I'll just go in there and change it, but other times we'll debate it. We have a GitHub repository behind the project, and the issue tracker is often where the debates happen.

Klein: Does HTML5 Boilerplate enable people to get started on HTML5 projects with many of these types of issues already addressed?

Irish: Partly. I originally started it to save time when starting an HTML5 project, but it quickly took on a bigger role. I now see it as two other things as well. It is an education tool, and it has become a great distributable package of best practices. Many things in HTML5 Boilerplate have a significant amount of data and research behind them that has been codified through the work of the front-end development community. So each technique contains a link to read more about it, and developers can be assured that each technique is a best practice. HTML5 Boilerplate is a great way to learn best practices in front-end development. Some people don't use the whole project, but others do.

Klein: What's the best way for a designer or developer who's still relatively new to HTML5 to become more proficient and begin using these resources you've created?

Irish: HTML5 Boilerplate is what the HTML5 front-end development community thinks is the best starting point for an HTML5-based site. It bakes in a lot of defaults, which are good. It also has a lot of documentation behind it, so many people read the documentation or the comments in the source code and learn so much without even using the code. I would recommend looking into HTML5 Boilerplate and the documentation behind it.

It makes sense to use Modernizer when you're implementing CSS3 so you have more control over how things look in different browsers. Modernizer also helps with using HTML5 elements.

Web resources like HTML5 Doctor and HTML5 Rocks, which release tutorials on a regular basis, also help people learn the correct way to use HTML5 and implement new features. All the recent HTML5 books are strong. Introducing HTML5 by Bruce Lawson and Remy Sharp is one of the best. These books are a great way to ease into HTML5. A lot of people have contributed code and written articles to make it easier for everyone else to learn the best way to do things.

Klein: Do all your web projects start with HTML5 now?

Irish: Yes. On a technical level, a browser will not treat an HTML4 or XHTML site any differently than an HTML5 site. It uses the exact same code paths within the browser. If you have an XHTML site and you change the doctype to HTML5, nothing will change. The browser will still render it the exact same way. The only real problem with implementing HTML5 is if you want to use <nav>, <article>, and <section> in Internet Explorer 8 and have it work fine with JavaScript turned off. That is the one problem that doesn't have a good solution yet. Other than that, essentially everything is taken care of. I can live with that one problem, and so can most people. Those hypothetical Internet Explorer 8 users are not experiencing the web the same way the rest of us are anyway. If your site looks bad to them, it's not going to break their hearts.

Klein: Where do you think HTML5 will make its biggest impact in the next couple of years?

Irish: The mobile web is really interesting. Because we don't have Internet Explorer 6, 7, and 8 on the mobile web, mobile browsers are already more capable than desktop browsers. The browsers are great, but the devices are slow, and they come in all different shapes and flavors, so it's a challenge.

I do think we're going to see more people making HTML5 games, not only for mobile but for desktop. Several great frameworks are available to make creating games in the browser easier and faster. When things like WebGL become available on more browsers, HTML5 games will become even better.

Klein: Can you quickly explain WebGL for those who might not be familiar with it?

Irish: Yes. WebGL is a flavor of OpenGL ES that enables JavaScript to generate hardware-accelerated 3D graphics. With direct GPU integration, you can get 60-frame-per-second, high-fidelity 3D graphics. Before WebGL, we had never seen this in the browser.

Klein: Are the biggest barriers processing power and a capable browser?

Irish: Yes. We're waiting for devices to become stronger, but that's happening incredibly fast.

Klein: What's next for Paul Irish?

Irish: I mentioned using tools to manage prefixes earlier. In the past two years, a lot of different tools have made development easier. Many people use TextMate or Sublime Text, plus several bundles automate common tasks with keyboard shortcuts. Sass, CoffeeScript, and Markdown are all projects aimed at making web developers more productive. One of the things I'm excited about is demonstrating how to use these smart tools in good workflows to make developers more productive and help them build the cool stuff they want to be building, instead of just focusing on getting things working.

I want to help people build amazing web apps without duplicating other people's efforts, and I want people to be able to tell the story of how their development workflow was improved by taking advantage of what's already available.

Klein: Do you have any other advice or recommendations to those reading this interview?

Irish: Yes. I'll give the same advice I offered at the .net Awards. I think it's important to publish what you learn. There's really no school for front-end development. You can't go to a university for a JavaScript degree or a class about how browsers work. Most of us learn from blogs and Twitter. Early in my career, I learned a bunch of things whenever I worked on a project, but I never told other people about them. So my general advice is to publish what you learn, share with the community, and collaborate on projects that help move the community forward.

Klein: That's great advice, and you're certainly backing up that philosophy with the fantastic resources you're putting out there for other developers.

Irish: Thanks. We published the site movethewebforward.org a few months ago. It shows developers how to get involved with the community by engaging at a standards level, helping browser development, or even setting up a personal blog. That site helps people of all different skill levels learn what they can do to help everyone else. It even offers ideas for topics to write about.

You can follow Paul Irish at http://paulirish.com/ or on Twitter @paul_irish.

‹ Back

---