Progressive enhancement scripting behavior in a

This preview shows page 129 - 131 out of 141 pages.

PROGRESSIVE ENHANCEMENTScripting behavior in a responsible way isn’t always easy. We’restanding in for the browser, taking over the user’s experienceof something as common and predictable as clicking on a link.Done in an unobtrusive way, we’re able to create a completelyfluid experience—better, in many ways, than the browser itselfcould.If we don't do it responsibly, though, we’ve done somethingfar worse than simply presenting the user with a misaligneddiv—we’ve built something they might not be able to use atall. The web is an unpredictable medium, and we have to planfor that—when writing JavaScript more so than HTML or CSS,by a wide margin.We could have cut some corners in the paragraph-togglingscript we built today, for example. We could have hidden thoseparagraphs at the outset using CSS and relied on JavaScriptto show them again, or hard-coded the Read More link andassumed the functionality in our script would always be avail-able. The latter case would be a nuisance if anything wentwrong—an error elsewhere in a script causing ours to fail, forexample. The user would be left with a Read More link thatJAVASCRIPT FOR WEB DESIGNERS124
didn’tdoanything. The former case would be far more dire: inthe event that JavaScript failed in any way, the user would beleft with no way to access the contents of the page.A site that fully relies on JavaScript for critical function-ality—a website built on the expectation that JavaScript willalways run, no matter what—is a fragile one. Users’ browsingconditions can change minute to minute, and we can’t plan for—we can’tknow—the ways that our scripts might break down.A handful of years ago I worked on the responsiveBostonGlobesite with Ethan Marcotte, Scott Jehl, and the whole crewat Filament Group. It was built with progressive enhancementin mind, which didn’t hold us back in the least—there are someincredible features on that site, if you don’t mind my saying so().We got to solve some tricky problems on that project, butmade sure we were doing so with progressive enhancementsquarely in mind—“If and when this feature fails, how do weensure the user still has access to the underlying information?”On the surface, that may seem like an exercise in edge cases.The tiny decisions that go into building a website don’t neces-sarily feel like a big deal at the time.The Boston Marathon bombings happened a few years later.Being able to reach up-to-date information on what was hap-pening throughout the city was tremendously important to ahuge number of people that day, and many of them looked totheBoston Globefor that. Due to the increased traffic, theBos-ton Globe’s CDN—the server that delivers assets like CSS andJavaScript—was overwhelmed, and went down. For a period oftime that afternoon, theBoston Globe’s website was HTML-only.The websitelookedbroken, and none of our advanced Java-Script features were there consistently: no offline reading, nodropdown menus in the navigation. Sometimes the wholesite was just black Times New Roman on a white background.

Upload your study docs or become a

Course Hero member to access this document

Upload your study docs or become a

Course Hero member to access this document

End of preview. Want to read all 141 pages?

Upload your study docs or become a

Course Hero member to access this document

Term
Fall
Professor
NoProfessor
Tags
Document Object Model, T F O R W E B D E S I G N E R S

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture