Everyone is into AJAX, or so it seems. We'll know for sure in a few years, but it sure looks like AJAX is here to stay. Google released their Web Toolkit and Google Maps API. Yahoo! released their Yahoo! UI Library and Maps AJAX API. And of course there are prototype, scriptaculous, and Rico. Now Adobe has an ajax library named Spry Ajax Framework.

Macromedia is Improving Adobe

I could be wrong, but I believe the appearance of this Ajax library is due to the merger with Macromedia. Have you noticed that Adobe's site is based largely on Macromedia's old site? Obviously, they keep most of the Macromedia site and now the domain www.adobe.com now points to it, rather than the other way around. That's a smart move on Adobe's part and I'm very glad to see it.

I'm very pleased to see this new Ajax library from Adobe. They have several nice demos and, true to Macromedia's style, some good tutorials, examples, and documentation online.

But there's a Catch

The Spry Ajax Framework is free. So that's not the catch. And you need to register with Adobe, but that's not the catch either. The catch is that it requires the use of non-valid HTML attributes (at least in their demo). The JavaScript code looked pretty sweet, but the HTML???

In reviewing the example code for the image gallery demo, I saw some code that I liked and some code that I didn't like. While I like the look of this code:

 
<script type="text/javascript">
var dsGalleries = new Spry.Data.XMLDataSet("galleries/galleries.xml", "galleries/gallery");
var dsGallery = new Spry.Data.XMLDataSet("galleries/{dsGalleries::@base}{dsGalleries::@file}", "gallery");
var dsPhotos = new Spry.Data.XMLDataSet("galleries/{dsGalleries::@base}{dsGalleries::@file}", "gallery/photos/photo");
</script>

The above code looks promising. You create JavaScript object to load XML files as a data set. Nice. But then further down the code, I started to get concerned. Adobe is using custom HTML attributes. I do NOT like the look of this code (note the adobe defined attributes like spryregion):

 
<div id="galleries" spryregion="dsGalleries">
    <label for="gallerySelect">View:</label>
      <select spryrepeatchildren="dsGalleries" id="gallerySelect" onchange="try { eval(this.value); dsPhotos.loadData(); } catch (e) {}">
        <option spryif="{ds_RowNumber} == 0" value="dsGalleries.setCurrentRow('{ds_RowID}'); dsPhotos.setURL('galleries/{@base}{@file}');" selected="selected">{sitename}</option>
        <option spryif="{ds_RowNumber} != 0" value="dsGalleries.setCurrentRow('{ds_RowID}'); dsPhotos.setURL('galleries/{@base}{@file}');">{sitename}</option>
      </select>
    </div>

Adobe's Spry HTML Attributes Fail Validation

Why Adobe chose to use custom HTML attributes is beyond me. They are not valid HTML and fail validation. When I run the W3 HTML Validator on Adobe's Spry image gallery demo, I get numerous validation errors about the custom attributes, for example:

Adobe's HTML Fails Validation

See for yourself. Run the same validation test.

Conclusion

I'm sorry but I can't take this demo from Adobe seriously. I will not use non-valid HTML attributes. Period.

A very good alternative would be to give the appropriate HTML element's a CSS class name and use a library like Behavior, a library used to identify HTML elements for JavaScript DHTML.

Come on Adobe. I was so excited by your new Ajax Framework, only to be let down. Oh well, there are plenty of other AJAX libraries out there ...