In this final chapter, we will learn:
- The fundamental difference between progressive enhancement and graceful degradation
- How to make older versions of Internet Explorer responsive
- How to use Modernizr to conditionally load CSS files
- How to use Modernizr to conditionally load JavaScript polyfills
- How to change long lists of navigation to select menus on small viewports
- How to provide images for high resolution (retina) displays
Before we get to the meat of this final chapter, let's recap where we are and what we know.
Mobile usage is exploding. Consequently users view websites with a variety of viewports (different sizes and orientations) and with varying bandwidths. For the foreseeable future, we need to design and build our websites starting with the essential content and layering on features and enhancements progressively. Furthermore, due to the bandwidth considerations, the code base should be as lean and flexible as possible.
Design-wise, we've embraced all three legs of the Ethan Marcotte responsive design methodology. CSS3's media queries (covered in Chapter 2, Media Queries: Supporting Differing Viewports) are used to create design breakpoints where the layout can adapt dramatically to the viewport. Then flexible images and media alongside a fluid grid (covered in Chapter 3, Embracing Fluid Layouts) to provide a smooth flex between these media query breakpoints. The result is a design that not only works for today's popular viewports but for the future's too.
To keep our code base lean, in Chapter 4, HTML5 for Responsive Designs, we switched our markup to HTML5. It provides economies, more semantic code, and makes features such as offline viewing possible. Going further, we added some WAI-ARIA accessibility to our code, providing additional aids for screen readers and assistive technologies.
In Chapter 5, CSS3: Selectors, Typography, and Color Modes and Chapter 6, Stunning Aesthetics with CSS3, we looked at the incredible power and flexibility of CSS3, learning about new RGBA and HSLA color modes and how common design flourishes such as box-shadows, text-shadows, background gradients, and so on can be achieved without images, using CSS3 alone. In addition, the powerful selectors of CSS3 have allowed us to select anything we need from the DOM, a level of selection power that previously required JavaScript. Yet CSS3 hasn't just given us the ability to adapt the design and drastically lower the amount of bandwidth required to view our site. It has also added functionality we could never enjoy before without employing Flash of JavaScript: custom typography (Chapter 5, CSS3: Selectors, Typography, and Color Modes) and beautiful smooth transitions (Chapter 7, CSS3 Transitions, Transformations, and Animations) between different visual states. Keeping one eye on the future, we also glimpsed at sophisticated features such as CSS3 3D transformations.
Finally, in the last chapter, we tackled the humdrum task of form building, relishing the opportunity to handle the heavy work of form validation and form UI element creation using HTML5 markup. Importantly, we also added a JavaScript fall back to conditionally enhance the experience for older browsers such as Internet Explorer versions 6, 7, and 8.
Throughout this book we've built up a fairly simple responsive website in HTML and CSS3 called And The Winner Isn't … . You can visit this site in your browser at http://www.andthewinnerisnt.com.
The following screenshot shows how the front page currently looks on an iPhone:
The following screenshot shows how the front page looks on an iPad:
The following screenshot shows how it looks in the Android browser (emulator):
The following screenshot shows how it looks in a modern desktop browser (Google Chrome v16):
Finally, the following screenshot shows how it looks presently in Internet Explorer 8:
Oh Momma! Pass the service revolver…
Looking at the site in Internet Explorer 8, which doesn't understand HTML5 elements, such as <aside>, <header>, <nav>, and <footer>, by default brings us to the thrust of this chapter—solving cross-browser responsive challenges.
You're probably aware of the phrases "progressive enhancement" and "graceful degradation". These two concepts are methodologies for dealing with wide and varied browser support and spark fierce debate within the web community. Whilst initially they may seem inter-changeable terms, they are actually fundamentally opposed. Here's my take…
Graceful degradation means creating a site for modern browsers and then ensuring that certain older browsers are afforded a usable experience. Features degrade in older browsers and there is usually a cut-off point in which the oldest browsers aren't supported. There are also occasions where users are merely warned that there is a problem with their browser and workarounds are suggested (for example, "your browser is a joke—get a new one!")
Progressive enhancement is the reversal of graceful degradation. Progressive enhancement begins with markup that adheres to web standards, meaning it will be usable by all browsers (irrespective of technologies such as JavaScript and even CSS). The experience is then progressively enhanced for more capable browsers through CSS styling and eventually JavaScript (if required).
There are hundreds of articles discussing the merits and failures of each approach. For starters, I'd take a look at this piece on the Opera developer's site: http://dev.opera.com/articles/view/graceful-degradation-progressive-enhancement/ and this excellent piece by Aaron Gustafson: http://www.alistapart.com/articles/understandingprogressiveenhancement.
Currently, progressive enhancement is largely considered to be the best practice way of developing a website. However, the cold hard truth is that whilst I fundamentally favor and build sites using the progressive enhancement methodology, there are plenty of instances where I am arguably doing things in a graceful degradation manner. How so?
The www.andthewinnerisnt.com site we have just built up uses HTML5 as its code base. Older browsers such as Internet Explorer versions 6, 7, and 8 (from this point on, also referred to as "old IE") were built and released before HTML5 (which you'll remember isn't a ratified standard despite its growing ubiquity) and so don't understand what <aside>, <section>, and <footer> elements are for. So, from a purist sense it could be argued I shouldn't be using HTML5 elements. By adding a piece of JavaScript to fix this basic functionality problem—is this really progressive enhancement?
Despite this, unless there is a compelling reason not to, I always opt to use HTML5 over HTML 4.01. The reality is that for the work I do on a week-in week-out basis, HTML5 offers more benefits than shortcomings. So, if using HTML5 (and I certainly recommend you do), give all devices the best shot at handling it natively by coding standards compliant HTML code (use the HTML5 validator at http://validator.nu/ or at http://validator.w3.org/ to eliminate any errors).
Regardless, there will inevitably be a point in which you choose (or are forced) to make some portion of the enhanced functionality afforded by modern browsers, possible in ailing versions of Internet Explorer. Maybe you want border-radius to work in old IE, for example. However, before you go there, I'm going to bend your ear just a little more…