The Web Standards Project » Adobe TF* http://www.webstandards.org Working together for standards Fri, 01 Mar 2013 18:30:30 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Spry turns two http://www.webstandards.org/2008/06/02/adobe-spry-turns-two/ http://www.webstandards.org/2008/06/02/adobe-spry-turns-two/#comments Mon, 02 Jun 2008 19:32:10 +0000 agustafson http://www.webstandards.org/2008/06/02/adobe-spry-turns-two/ 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™.

]]>
http://www.webstandards.org/2008/06/02/adobe-spry-turns-two/feed/ 1
Announcing the Adobe Task Force http://www.webstandards.org/2008/03/10/announcing-the-adobe-task-force/ http://www.webstandards.org/2008/03/10/announcing-the-adobe-task-force/#comments Mon, 10 Mar 2008 17:27:58 +0000 Stephanie (Sullivan) Rewis http://www.webstandards.org/2008/03/10/announcing-the-adobe-task-force/ The Web Standards Project Dreamweaver Task Force was created in 2001 to accomplish two tasks: to work with Macromedia (later Adobe) to improve the standards compliance and accessibility of Web pages produced with Dreamweaver and to communicate effectively within the online Dreamweaver community. Having successfully completed its initial goals, WaSP announces that the Dreamweaver Task Force will be renamed the Adobe Task Force to reflect a widened scope. The Adobe Task Force will collaborate with Adobe on all of the company’s products that output code or content to the Web, and will continue to advocate compliance with Web Standards and accessibility guidelines by those who use Adobe’s products to design and build Web sites and applications. Read the press release to learn more.

]]>
http://www.webstandards.org/2008/03/10/announcing-the-adobe-task-force/feed/ 16