The Web has always had a level of fault tolerance. Think about it—if you miss a closing angle bracket in your HTML, the browser still renders the page. If you misspell a CSS property, the browser still renders the page. This is one of the things we love about the web: it’s scrappy, it’s robust, and its default position is that people should get access to the content we publish using it.
Enter the web designer. A creature many of you are familiar with. We’ve had a long history of breaking things. When we couldn’t get the crazy layouts we wanted, we used tables to do so. When we got frustrated with text wrapping and line-length, we fixed the width of everything. And when we created ways to load content with JS, many of us stopped caring about fault tolerance.
This month, the topic for The Shift is “Progressive Enhancement.” At its core, this idea is about embracing the fault tolerance of the Web. Start with the simplest of acceptable experiences (typically static content via HTML), layer on the design or presentation of that content (typically using CSS), then layer on interactions (typically using JS). But there is a cost to working this way, and it can be difficult to make the case for this approach to business owners.
Because there are so many perspectives out there on this topic (and Sparkboxers love to debate), we invited a handful of folks from our team to share their thoughts. Our hope is that this spurs you to consider these various perspectives, to challenge what you’ve always believed, and—perhaps—even to change the way you work. Read on…
A Project Manager’s Perspective
When I reflect on Progressive Enhancement as a project manager, the order work is done feels like a major driving force. The order you do things is important beyond just developer workflow. I (and Sparkbox) want to make good decisions with our clients. We want to set them up for success. And the truth is that on essentially all projects, scope creeps and timelines and budgets have to adjust in some way. What you leave for later stands the best chance of being taken out of the project. Picture being told the following versions of a project update:
“We have this thing working precisely like you wanted. Now it’ll just be another 15 hours to get it working in all those less desirable places you only partially care about.” versus
“We have the core basics of this working everywhere. Now it’ll just be another 15 hours to make it do all the super fancy stuff we talked about as enhancements.”
And imagine you have 12 other items on the to-do list that are just as big. How easy is it to decide that a certain browser or noJS solution just isn’t worth the time and investment in version 1 compared to version 2? If you want to purely and naturally achieve Progressive Enhancement without arguing about why it needs done, you need to take care of the basics first and put off the stuff everyone gets excited about for later; otherwise, you’re going to leave some people out of enjoying any of it. At Sparkbox, project managers are the ones who are going to have the scope/budget conversations with a client and help give direction to the team. If you set the expectation with everyone that you’ll start with the basics and enhance, you’ll stand a much better chance of achieving Progressive Enhancement team harmony.
A Web Designer’s Perspective
The Web is a huge world with people who use it in so many different ways. Designers like me use the Web at full throttle—nice computer, lots of bandwidth, riding the tech wave to Net Town. Those with sensory disabilities use the Web in an entirely different way, relying on assistive technologies like screen readers to access information. And then there are those in second-world countries using the Web for a more narrow purpose and relying on QWERTY keyboards on next-to-no bandwidth. Yet, all of us have the same goal when we get to our keyboard: we are all accessing content.
At the heart of Progressive Enhancement is the idea that we need to get content to our users, no matter what. We want to start with a site that is accessible to anyone, anywhere. Many technologies, ideologies, and techniques have sprung from this idea. Responsive websites get content to users despite their screen size. Performant sites get content to users despite their bandwidth. Accessible sites get content to users despite their disabilities. These things are all considerations in Progressive Enhancement.
Progressive Enhancement is about providing access to everyone using the Web, and leveraging accessibility techniques is a necessary first step in Progressive Enhancement. Creating a site with a baseline of content that has been run through the accessibility ringer, markup that’s using ARIA elements,
alt tags, all the good stuff—Progressive Enhancement moves forward from this launching pad. If our site isn’t accessible to everyone from the start, then what’s the point?
A CSS Developer’s Perspective
The beautiful thing about the cascade is its inherent progressiveness. As the browser travels down the stylesheet, it applies properties it recognizes and skips the rest. Writing CSS that progressively enhances is a natural part of the language. But to write effective CSS that enhances well requires having a good grasp on older approaches and techniques. As Carl Sagan stated so well, “You have to know the past to understand the present.”
Let’s take a look at how we handle layout these days. We have been using floats as our primary way to control layout for many, many years, which has been somewhat problematic since floats were not initially created to control layouts. We’ve had to figure out ways to clear those floats and be very specific with container dimensions, and then there are those weird wrapping bugs. That is where flexbox comes in: it’s a solution to float layouts and other layout inefficiencies of the past. A particularly fantastic aspect of flexbox is that it‘s designed to respect the cascade. Its properties can largely live alongside other properties. Flexbox overrides floats, so the old way of aligning content can still be used, and then the new way can refine and enhance that alignment.
You may have noticed the doubled
display properties in the CodePen above. This gets into what I love about the cascade for Progressive Enhancement. Properties, if supported by the browser, are overwritten the further down the cascade they reside. So in the above case, if a browser does not support flexbox,it will apply the
display: block; however, if the browser does support flexbox, that browser will understand and apply
Now if we continue with this example we will run into situations where browsers get weird. Sometimes browsers half-implement a property, which can wreak havoc on an otherwise peaceful cascade. Or perhaps adjustments are needed on other styles when a particular property is supported. This could certainly happen with flexbox, as refinements to the column may include adding some margins. A great detection tool for browser features, like flexbox, and one that’s amazing for Progressive Enhancement is Modernizr. We can enhance our styles based on the presence of classes Modernizr adds to the
html tag. The CSS from above could be enhanced with Modernizr classes like so:
See the Pen Flex Progressive Enhancement with Float Fallback (with Modernizr Classes) by Philip Zastrow (@zastrow) on CodePen.
This will apply a `margin-left: 1em` and a dark grey left border to `.right` if Modernizr detects that flexbox is supported by the browser. Otherwise, these properties will be skipped since the browser cannot find an element with that scope. Modernizr is a unique and useful tool that allows precise control over progressive enhancements without relying on hacks.
Progressive Enhancement is an important part of building an inclusive website. Reliance on the cascading structure of CSS makes Progressive Enhancement easily attainable.
A React Developer’s Perspective
React has been making waves in the frontend community for a couple years now. It began its life inside Facebook as a way to address a few core problems its web teams were facing:
Integrate whatever solution they came up with into their existing codebase incrementally without having to do a full re-write.
Allow rapid development of self-contained components that are easy to understand.
A Technical Director’s Perspective
As Technical Director here at Sparkbox and consultant before, my goals shuffle between giving our super-talented team an opportunity to shine and helping our clients make informed decisions. While the latter might not always seem to align with the former, I believe building the right product is the best way for us to shine, and I’d like to talk about why Progressive Enhancement is an important tool in making smart business decisions.
We should be past the point of convincing readers of the importance of the web to our economy. Suppose that we also agree that the Web will continue to influence markets, which so far, felt immune. More interesting than if is how a business should effectively leverage the Web to build and grow a place in their market.
The last few years, much of the web industry’s work has been focused on supporting the myriad of devices in use. In 2014, we saw a 20% growth of smartphone sales. Fast forward just a few short years and we can expect a third year of declining smartphone sales growth to 7%, while connected “things” will grow 30%. With those devices people are purchasing less of, more of them are being used to search via voice and engage in augmented reality-based marketing.
At the same time, we can expect demographics to change. In 2014, the fastest-growing internet population actually lost ground in broadband performance and capability. Heck, even suburbia has a poor connection upstairs.
While the Internet around us continues to evolve, a few things remain consistent: humans are impatient, and computers prefer structured data. Progressive Enhancement is an invaluable set of principles that help businesses play in a shifting sandbox with fickle customers using feature enhancements prioritized for devices and conditions that deliver the most value to our business. Toss aside the dogma and begin making clear, conscious choices about features that are worth the cost of optimizing for a market segment.
It Takes a Village
To do this stuff right, it takes commitment and buy-in from the entire team. Progressive Enhancement is not something you can tack onto the end of a project. In fact, you’ll struggle if you try to do it without involving your client or stakeholders.
But it’s so important.
The fault tolerance of the Web gives it more power than any other communication technology, but we are responsible for following patterns that allow this power to surface. Yeah, you and I can totally ruin it, but we can also make it beautiful!
So take the time to understand how you can use Progressive Enhancement techniques in your next project, and get to work.
Many thanks to Austin for wrangling the ideas above.