You’re excited; your client is excited. All is well. You’ve just launched the client’s latest website, and it’s fantastic. You’ve put in hours of sweat and tears, tweaking every little detail of the design—expanding menus, interactive Ajax, all the latest bells and whistles. It looks good, works perfectly, and everyone’s partying. But a week later disaster begins. The client phones in a panic; it seems they’ve been getting calls from some customers who can’t get past the home page, and others are having problems with some aspects of the feedback form—but it works fine for you and the client. Other people have been calling and complaining that the site is taking too long to download each page, even though it doesn’t look like there’s much on the page, and you barely notice the load time. To top it off, the client has found that its search engine ranking has plummeted from number one to nowhere. Things are not good after all. But where could you have gone wrong? Let’s find out.

Best practices are accepted and tested models for the way you should go about doing things. They’re not necessarily the only way or even the best way, but they’re the way the majority agrees things should be done. Most of the time, best practices are mentioned near the end of a book, more as a reminder that once you’ve learned everything and you’re on your way, there’s actually a proper way to do it. I’m putting best practices up front, because I want to guide you in the right direction before you learn anything new. There’s no point in going down dark roads of frustration when there’s already a well-lit road ahead.

Unobtrusive and progressive enhancement

Extensible HyperText Markup Language (XHTML), Cascading Style Sheets (CSS), and Document Object Model (DOM) scripting using JavaScript are the big three of web design. XHTML provides the semantic meaning in your document structure; CSS provides the positioning and style for your document layout; and DOM Scripting enhances your document’s behavior and interaction. Did you catch that? I said DOM scripting enhances, not provides, your document’s behavior and interaction. The difference between “enhances” and “provides” is an important distinction. We’ve all learned about XHTML,semantics, and validating our documents so they conform to the W3C specifications, and we all use CSS to properly style our semantically marked up XHTML strict documents (you do, don’t you?), but DOM scripting, the third piece, the one that makes things extra slick and gives your web applications extra flare, can be an obtrusive beast.

DOM scripting relies on JavaScript. If you search for “Unobtrusive JavaScript” on the Web, you’ll find a flood of different descriptions, but that’s only because unobtrusiveness needs to be considered everywhere. It’s not a Band-Aid you can just throw onto your code to make it all good. There’s no unobtrusive object in JavaScript (Hmm . . . maybe there could be?), and you can’t download some “unobtrusive” library to fix your code. Unobtrusiveness is only possible with proper planning and preparation in your web application. It must be considered when interacting with both the user and the web developer. Your scripts must be unobtrusive to the user and avoid unnecessary flashy and annoying features (something that gave JavaScript a bad rap in the past). Scripts must also be unobtrusive to allow the page and markup to continue to work, though maybe not as elegantly, without JavaScript. Finally, they must be  unobtrusive and easy to implement within your markup, using ID and class hooks to attach behavior and provide a separation of the script from the markup. To better understand unobtrusiveness, and the integration of DOM scripting, XHTML, and CSS, you need to consider the outcomes in the situation we looked at previously and understand the basic principles and
their application to your code.

Two methodologies you often hear about with unobtrusiveness are “progressive enhancement” and “graceful degradation.” Browsers that lack certain features should receive an equally informational,yet altered, view of the same document by using techniques that either enhance the document as technologies are available (progressive enhancement) or degrade the document when they are missing (graceful degradation). These two concepts are often used interchangeably, but each embraces the idea that not all browsers are created equal—and not all browsers should be treated equally. Also, you shouldn’t force a low quality service on everyone just to be able to cater to the lowest common denominator.

One of my favorite quotes about the necessity of progressive enhancement comes from Nate Koechley of Yahoo, who sums it up when describing browser support  (http://developer.yahoo.com/yui/articles/gbs/gbs.html):

“Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have the identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.”

If you’re using JavaScript in a way that inhibits the “availability and accessibility of content,” you’re doing something wrong.

At the same time, progressive enhancement doesn’t necessarily mean an all-or-nothing approach to JavaScript. The problem is that, unlike most programming or scripting languages that you would run on your own dedicated servers or computers, JavaScript is an interpreted language that runs within a web browser, so you won’t have any control over the wide variety and mix of software, hardware, and operating systems your script will need to handle. To deal with the infinite combinations, you have to be careful and create behavioral enhancements based on the capabilities of the browser and the available technologies, which could mean providing a degraded solution that still relies on lesser parts of JavaScript or a solution that falls back on traditional, JavaScript-free methods.

I’ll be stressing these ideas of unobtrusiveness, degradability, and progressive enhancement throughout the book, but I’ll also say that I am by no means a zealot. I do realize that your sites do need to support browsers without standards-compliant features. In many cases, proprietary methods will also be required, but the trick is to go for the standards-compliant way and only fall back on the proprietary way if necessary.

When working with DOM scripts and integrating them into your site, you should always write scripts
that are
Standards compliant: Future-proof your application and ensure that your web application will
continue to support newer and better browsers.
Maintainable: Incorporate reusable and easily understood methods so that you and others can
focus on the business task at hand, rather than rewriting the same things over and over.
Accessible: Ensure that everyone can easily and efficiently access your information, even those
without the script or JavaScript enabled.
Usable: Something that works great in one situation but is hard to implement or replicate isn’t
going to be much fun the second or third time around. Usability applies to both the interaction
with the end user and the interaction with developers.