Working together for standards The Web Standards Project

Two years ago, Adobe introduced their JavaScript framework: Spry. As Drew pointed out a few days later, that preview was somewhat lackluster in the standards department, using custom attributes and obtrusive JavaScript techniques.

Two years on, the framework is at version 1.6.1 and has made some solid movement towards being more unobtrusive—even going so far as to offer a “make JavaScript unobtrusive” option in the Dreamweaver CS4 beta—and, for that, I applaud them.

As frameworks go, Spry has some nice features—such as turning arbitrary HTML into a dataset to name one—and is maturing rapidly. This version of Spry still seems directed at the novice programmer or people who feel more comfortable working in a tool like Dreamweaver, but I easily recognize the influence of other frameworks on this toolset, showing that they have an eye on the hardcore programmer audience as well. They’ve also made it easy to work around the custom attribute issues that earned them so many lashings when Spry first hit the scene.

It isn’t all wine and roses though; I have two major criticisms of the framework as it stands today, and they’re directly linked.

First off, while the framework makes it really easy to build out widgets from its stable and hangs most of that functionality from class names, Spry defaults to requiring a lot of extra markup in the document in order to tie together widget behaviors. These controls are usually hidden with a slathering of display: none and shown when the script runs, which is a step in the right direction, but still misses the mark.

Why include that entire markup in the document in the first place? If someone doesn’t have JavaScript enabled, why force the download of that extra markup? Widget components like next and previous links, etc. have no business being in the document if they are useless regardless of whether they are hidden by CSS.

Which brings me to my next criticism: the documentation.

The documentation for Spry is pretty thorough, with lots of examples, but none of those examples truly demonstrate the proper way of doing JavaScript. It’s pretty obvious that the developers who wrote them were quite familiar with Spry and far less so with current best practices, especially in regards to progressive enhancement. The examples are riddled with markup that is required for the JavaScript widgets to function despite the fact that it could be quite easily generated at run-time.

At this point Spry has yet to alias any of the DOM node creation methods to their framework, which I would have thought would be one of the core features in SpryDOMUtils.js, but that still doesn’t excuse them from using the native DOM methods like createElement(), createTextNode(), and so on to do the work. In fact, I was shocked to find that the only place Spry is actually generating markup into the document is when its debugger is in use.

While I do think these two issues are critical for Adobe to address, neither is difficult to overcome. An overhaul of the example files with a clear focus on progressive enhancement techniques is a no-brainer. Adobe offers some progressive enhancement with Spry information, but the documentation could go further.

Adobe’s own Greg Rowis has attempted to fill the gap by posting instructions on his personal blog for creating a more unobtrusive dynamic accordion list. Taking the lead from Greg, Adobe should devote some serious time and effort to showing how to use its framework The Right Way™.

Your Replies

#1 On July 25th, 2008 11:11 pm Spry turns two « AccessTech replied:

[...] Posted on July 25, 2008. Filed under: Access Issues | Spry turns two [...]

Post a Reply

Comments are closed.