What is a Modern Browser?

The other day, Mozilla Tech Evangelist Paul Rouget explained why he doesn’t consider IE9 to be a modern browser. The IE team at Microsoft, fairly, responded to Paul’s critiques, albeit with a bit more marketing fluff than needed. Superficially, this thing basically comes across as a teenager’s spat, but who’s right? Or rather, more importantly, what should we consider a “Modern browser” in today’s landscape, anyway?

As the Project Lead and original creator of Modernizr, and in general as a web developer who lives on the cutting edge of web-based technologies, I have a pretty specific opinion of what I consider to be a modern browser. In a nutshell, I would describe it as this:

A modern browser is any browser that: successfully renders a site that you just built using web standards, testing only in your browser of choice along the way, with all the essentials functioning well; without you having written any browser-specific hacks, forks or workarounds; and shows great performance as you navigate it.

That may not explain it clearly enough, so let’s break it down:

Successfully rendering a site

This is an obvious one. The layout needs to look right for everything that is essential. Rounded corners are not essential (though a pretty big nice to have these days). No, what I mean is that columns, grids, headers and footers, it all needs to be in the right place; not overflowing or being off by many pixels due to incorrect CSS handling. If I put in a detail using rgba(), then as a good web developer I either 1) double it up in CSS with a non-rgba() property declaration first, 2) use Modernizr for a workaround, or 3) acknowledge and accept that it won’t be rendered by a non-rgba() supporting browser. This kind of granularity does not a modern browser make, but if something like rgba() is implemented, it shouldrender exactly as I specified it.

The above (and below) assumes that my markup and CSS are correct, which is not always the case of course but when it’s not, I may be at fault (and so won’t hold it against the browser) but I still expect the browser to do its best rendering it anyway. Error handling is one of those things that really highlighted the differences between browsers in the early days; fortunately, today’s browsers are all pretty great and consistent in this area.

When I finish building a site’s first pass and start opening it up in other browsers to begin my testing, a modern browser will render it so accurately close to my main-use browser that it either is completely correct, or the things that are different are very hard to spot at first glance. All matters of positioning and flow should be as-specified, with no deviation.

A big part of what makes this happen in modern browsers is support for CSS3 Selectors. IE9 does quite well in this area, meaning most everything I do won’t require the use of Selectivizr.

Testing in your browser of choice

My main-use browser is Chrome (version 10), but feel free to substitute whichever latest-release browser you prefer. A good web developer builds & tests with the most standards-compliant browser available, compromising on small details only for the sake of the development tools they prefer. Disputes (the aforementioned small details) will always persist on which browser is the most standards-compliant, but it’s pretty irrelevant as long as you’re using the latest release, and your browser is capable of all the features you’re implementing in the site.

Platform independence is a consideration I have to acknowledge, which is where IE falls short (and Safari a little bit, but given that Chrome and Webkit nightlies are available on Linux, I consider this negligible). That said, among really cutting-edge web developers the overwhelming majority seem to use Macs. That’s not to say you can’t be a really cutting-edge web developer if you use Linux or Windows (e.g., some of the best I know run Linux on their Mac hardware), but odds are you’re using a Mac, and of the Windows-using segment, odds are you use Chrome or Firefox.

This is not some sort of roundabout evidence that IE9 is not a modern browser, or not good enough for cutting-edge developers to use as their main browser. Rather, it simply reflects how long IE.x has historically lagged behind other browsers in terms of standards-support and, very importantly, developer tools. IE9 could well be the first of the IE range to be modern enough to compete again, in fact.

All essentials functioning well

I take my craft seriously, so I make sure my sites’ content remains accessible with JavaScript disabled. I’d almost say “don’t break with JavaScript disabled,” but then I’d have to make a pretty strong exception, as I no longer care for browsers that don’t understand new (HTML5) elements without JavaScript. I’m now very close to the point where browsers, not just IE8 and below, will get a near-unstyled page if they have JavaScript disabled. Content can—and should!—always be functional and accessible, but style and behavior are “luxuries” we cannot support being absent in the Web of tomorrow. With HTML5 and CSS3 having so much integration and reliance on JavaScript for decent (event) handling and processing, I feel it is not reasonable to rely on one but not the other when building for tomorrow’s Web.

So presuming we have a modern browser with JavaScript enabled, all of my progressively-enhanced interactions and behaviors should function as expected. This doesn’t mean niceties like having no UI blocking with large operations passed to Web Workers, or dragging & dropping files from the desktop into the site. It does mean I don’t have to resort to polyfills and shims just to make the site usable for its audience in this modern browser.

No browser-specific hacks, forks or workarounds

The last item already touched upon it, but to be more precise: I should not have had to write any browser-specific code, or use an IE-only stylesheet or anything like that, for this modern browser to do all the above.

There is a component here that is a little bit difficult to quantify, which is forking code based on Modernizr’s feature detections. I frequently use the if/else construct that Modernizr enables me to use in both JavaScript and CSS, and one might be inclined to think that this is browser-specific forking—except it’s not. It is very much feature-specific; just because we may internally have the knowledge to map certain features as being present or absent in certain browsers, doesn’t mean that forking code based on features is, in and of itself, browser-specific forking. Hence, I don’t consider a browser “not modern” just because it uses some of my Modernizr-directed forks.

Great performance

Provided I’m not doing something dramatically complex with multiple background images and/or CSS gradients, or obvious rendering challenges like an over-abundant use of text- and/or box-shadow, opacity or fixed-position backgrounds, scrolling around the site should be smooth. Interactions with buttons, forms and JavaScript-handled events should be snappy. Animations should be fluid. This is all in the context of the afore-mentioned complexities being handled and rendered properly, and a modern browser should perform well on all of these.

GPU hardware acceleration is great, especially if or when it powers everything that animates, but battery consumption on mobile devices is a real concern that puts this solidly outside of the realm of being a requirement for a modern browser, to me. There isn’t much yet that we do on the Web that is so dependent on being GPU-powered, that we as developers can legitimately expect every modern browser to have it. Those types of features are what I consider the cutting edge today, not the modern standard. Which brings me to my closing point…

Cutting Edge vs. Modern

Rouget’s criticism includes a list of features that IE9 doesn’t support, but what he blatantly omits to disclose is that most of those features are not supported in Firefox 3.6 either—still the latest stable, public release of that browser. Sure, IE9 is in beta and so is Firefox 4, but that doesn’t mean they are on equal footing. In today’s browser landscape, there is an almost madman-like obsession with being the first to implement every latest concoction the WHAT WG and W3C come up with that seems useful. While that’s great for us web developers who want to use these features and let our imaginations and creativity run wild, it puts inordinate amounts of pressure on browser vendors to do rush jobs with perfect execution. This is unreasonable, and the bigger the browser’s installed base is, the more unreasonable it is.

Case in point: Firefox 4, which is itself catching up to the baseline set by Safari and Chrome, in some cases two years ago already. And in some (if rarer and less widely used) cases, Opera leads the pack of them all.

I’m really glad that Firefox 4 is adding support for so many things I consider essential components in my arsenal for building a fast, lean, clean and richly semantic website with a great user experience, I really am. But the stuff I’m referring to, I consider to be more cutting-edge than a baseline for making a modern website. Modern, to me, is supporting all the things I explained in great detail above. Web Workers, File API, Drag & Drop, CSS3 Flexbox, HTML5 ApplicationCache… these things are all cutting edge. That doesn’t mean we should be hesitant to use them, or that we have no legitimate use cases for using them; it means that when we use them, we’re building cutting-edge sites (and apps), not just modern sites. And that’s great! But we mustn’t conflate things.

Features that haven’t yet been supported / implemented in at least the last one public and one nearly-done beta release of each of the majority of today’s five main browsers (IE, Firefox, Safari, Chrome, Opera), are plain and simple cutting edge features. If you use them daily, that’s great, but you’re in avery small minority of people who do. With that in mind, I came up with a semi-serious “Modernity Rule of Thumb” for browser vendors:

When three or more different browsers support a feature in their latest public release, your next version should start supporting it as well.

Using that rule of thumb, we can eliminate most things from Paul Rouget’s list, because Webkit-aside, most all of it is a new feature for Firefox 4 or Opera 11, although a few were in Firefox 3.6. Still, how, then, does IE9 stack up to all the browsers?

Pretty good, in fact. But it’s not quite on par yet. For instance, it curiously supports the new box-shadow property, but still does not support text-shadow, even though that originally emerged in the CSS2 specification and was later punted (for only marginally-valid reasons) to CSS3. Nonetheless, text-shadow is one of those features that greatly aid us in making rich type really powerful, and it baffles me that so much time and effort was spent implementing and highlighting IE9’s typography support when such a simple yet nearly-crucial aspect to it was left behind. Also, IE aside, the last holdout on text-shadow support was Firefox, which now has two versions supporting it.

Features like CSS Transitions are obviously a great thing to have available to us in every major browser, but even there, Firefox itself is only adding it in its next release, the still-in-beta 4. So while long-available in Webkit browsers, CSS Transitions are still very much a cutting edge feature.

Same with CSS Gradients, which I think is extra fair to be lenient about because that spec has four different implementations in browsers today (three if you only count non-proprietary syntaxes).

An exception might’ve had to be made for the HTML5 History API, however. Especially in light of the recent challenges major websites are discovering inherent to the use of hashbangs, broad support for the fantastic new HTML5 History API would put that web-breaking practice to a swift end.

All those features that Rouget listed are nice to have available to us as web developers, but few are so widely supported across the public releases of multiple browsers that it’s folly to consider them the modern baseline. Some may argue I place that baseline too low, too basic; I would argue that theirs is unrealistic, even misguided.

It’s good for there to be a difference in what is modern and what is cutting edge; it’s okay if features from the latter are volatile and occasionally break; it’s not okay if something we consider “modern” suddenly breaks or becomes inaccurate because the specification changed. I for one am quite happy with the progress IE9 has made. There may be a couple of things I think should really be added before it becomes final—HTML5 History and text-shadow in particular—but I won’t cry foul much when (if?) that doesn’t happen.

Websites needn’t look the same nor be experienced equally in every different browser. If you’re looking for a world wherein the stuff you build will look and work the exact same in each browser, I wish you good luck because you’ll never live in one. Our web of today, and the web of tomorrow, is a place where the constraints are not defined by screens, browsers, features or devices, but our own (in)ability to build adaptive, flexible and naturally-evolving products that live online.

If you liked this, you should follow me on Twitter!