As you know, there is a lot more to building responsive websites than width. You need sensors that give you feedback to adjust sites based on other factors.
In front-end development, developers used to adjust a site to fit the constraints of the layout engine used by a particular browser. In 2003, there were only three browsers: Netscape, Internet Explorer, and Opera. Firefox, Safari, and the first mobile browser, Opera Mini, were released by 2005. Chrome wasn’t released until 2008.
Currently there are five major browsers, each with its own mobile version. Across that array of browsers, there are also older versions that users haven’t upgraded. In the same way that creating multiple layouts for multiple screen sizes eventually becomes a zero sum game, so does building multiple front-ends for multiple browsers.
We’re using responsive web design to accommodate new, cutting edge mobile browsers. But, while accommodating new browsers, it’s important not to do so at the expense of older browsers.
Historically, optimization has come as a product of building a site for the most popular browsers and then tweaking to ensure the site looks the same on a set of popular browsers. Designs would have to accommodate the capabilities of all browsers.
Progressive enhancement is one strategy to cope with browsers’ failure to support modern features. There is a temptation to build for the most up-to-date features, but, in a responsive web, the design of a site is contextual to the frame that it’s being viewed through. Responsive web design has become popular because it resolves the most obvious changing context — the size of the frame — but the context of a browser runs much deeper than it’s viewport size.
SVG makes for a great solution for high-resolution displays, but what about its support in older browsers? It’s not supported in IE 8 or older, so you have to build in a fallback if you support that browser. You could identify the browser and serve alternative styles against that browser but then you would have to serve those same alternative styles for every browser that doesn’t support SVG.
Wouldn’t it be easier if you could just write a style that would be used against every browser that didn’t support SVG? That way, you wouldn’t have to keep up with bug reports from the users of older versions. You could just set the fallback once and forget it.
If you have Chrome and have enabled DevTools, open your browser’s web inspector by right-clicking on a page and selecting Inspect Element. Then, click on Console and, after the caret, type “navigator.userAgent” and hit Enter. This will return your current browser’s user-agent, which is a string of text used to identify the browser in use. Chrome returns the following:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.35 (KHTML, like Gecko) Chrome/27.0.1443.2 Safari/537.35
In a lot of ways, the navigator object is the one of the best sensors we have available to us to inform our system about what our user is capable of; however, it’s not very future friendly. It bases your site’s actuators on a lot of assumptions about what the browser does and does not support. It also is unreliable because users can configure it to access sites that the browser might not be able to support.
What Modernizr does
Modernizr also applies a set of classes to the HTML tag, giving you the ability to modify the page’s CSS using the corresponding CSS classes. These CSS classes allow you to use CSS systems to build actuators that will adjust your pages to allow the progressive enhancements available for a page.
This comes in handy when you know you only need a certain set of tests. For instance, your site might not take advantage of CSS box-shadows, but it might need to support CSS gradients. Using the build tool, you can include the tests you need and exclude the ones you don’t need, keeping the source code trim and your user’s total load time down.
For our example, I’ll be working of the development version. I find that when I’m building a site, it’s best to work with the full version and then once you know what features you’ll be using in your site, trim the version down.
Using Modernizr for cross-browser CSS
Let’s do some simple feature detection with Modernizr. We’ll start with a raw sample site.
Let’s use this small test to detect whether or not our browser is capable of supporting SVG. For the sake of simplicity we’ll just add two span tags to the page to detect support.
<span class='yes'>Huzzah! You have SVG support.</span>
<span class='no'>BOO! You don't have SVG support.</span>
If you test this in a browser that supports SVG, you’ll see the message “Huzzah! You have SVG support.” whereas if you have a browser that fails to support SVG, you’ll find the “BOO! You don’t have SVG support.” message.
This example is pretty rudimentary, but it displays the core idea of using Modernizr to fix cross browser issues. If we were doing this same fix using the old user agent method, we would have to have a style sheet for each browser that doesn’t support SVG and change our CSS for each one. (For anyone interested, the only major browsers lacking SVG support are Internet Explorer 7 and under.)
By adding the svg/no-svg class to the html on the page, your CSS now has a selector that can be used to override existing CSS rules. Because it’s on the parent-most tag, it can used to override other classes on the page.
So, in this case, both span tags are given display:none;. If there is no SVG support, the display:inline declaration on the span tag with the .no class overrides the display:hidden thanks to the no-svg rule on the html tag.
Let’s try a more useful example of the same idea. We might want to have an SVG background image on the page, which falls back to a PNG if the browser doesn’t support SVG. By default we’ll use the PNG image. This way, the SVG isn’t served unless it’s needed and becomes a progressive enhancement.
Now we have an awesome SVG skull that will look awesome and crisp for users with high-resolution displays, and still look good for users with older browsers.
There is a great wealth of information to be learned about Modernizr. We showed you how it does the work of cross-browser capability without having to remember or maintain a running list of which browsers support SVG.
It functions exceptionally as a system with which to serve your user actuators to create speedy and highly functional websites.
Do you use Modernizr in your projects? What other methods have you used for serving responsive content? Let us know in the comments.
Featured image/thumbnail, divergent lines image via Shutterstock.