Why Spry? Part 2

So last we left this question, we had decided to build a toolkit and had some guidelines in mind. These guidelines took into consideration the need of our users, the desire to make Ajax easier to implement and some ideas about markup.

Early on, we started with the data set/region idea. It seemed flexible and easy to build, once the basic concepts were understood. We liked the idea of data references. We didn’t want to needlessly invent things either. XPath was the obvious way to traverse XML files for the data set We tried to stick to conventions with naming data references, etc.

We started with using the class attribute to denote regions (It wasn’t called “Spry” yet….but I will call it such here.). We could do things like: <div class=”ds1″>. Spry would search through the classes and find those nodes with the data set name and know to process them. And then we could do things like <div class=”ajaxrepeat”> and Spry would know to loop over the data set.

But we quickly ran into issues. Loading the class attribute makes for tougher management of both CSS and Spry stuff. Then we thought about Dreamweaver users and the way that class management works. It could lead to trouble. We also were flummoxed when it got to things like if/then statements (today’s spry:if and spry:test). How to do that in a class or id attribute? We were overloading the class.

There were also some other issues to deal with. We tried to use XSL/XPath for real time transformation, but the browser support wasn’t there for it.

We tried using comments to contain the Spry logic, but Safari strips out comments when it loads the page.

We were a bit reluctant but we went to custom attributes. This gave us the freedom to do what we wanted to do. It also freed up the class for just CSS. It also made the page much easier to follow. The attribute stuck out and it was easy to look at the page and parse the flow, not only visually, but in the actual computation as well.

So we went with custom attributes. That let us get into the bulk of the Spry development, as we proceeded to our first release. We had many brainstorming sessions, debating the merits of one workflow over another, running into stumbling blocks and having to change things around. At this time, there were only 3 of us on the team, working on the side as we worked on Dreamweaver. We tried to identify the 80% cases for certain features and work flows.

It was nice to see our concepts come to life. We were leveraging CSS and HTML for template foundations and peppering them with attributes to kick off the Ajax functionality.

But now that we had our handy little attributes, we had new concerns, standards being the first of them. We were loath to break validation. We knew we could name space for validation concerns. The standards part was tougher. Was this innovation worth not being standards compliant? The pull between standards and innovation is a tough one. On one hand, as Adobe, we have a high standard to follow. As a small team trying to do something new, we needed room for flexibility.

The accessibility issue is tough too, not just for us but for all ajax frameworks. In a nutshell, the XML data doesn’t show up as part of the markup. This means that screen readers don;t have anything to read. Part of the trouble is that we are dependent on 3rd party applications for accessibility. Users will seek out the application with the best support, but knowing the state of these apps, it puts a burden on us to develop with accessibility high in mind.

We will cover these ideas in the near future.

But in our narrative, we had the basics of what would be Spry pretty well developed. Kin was heads down, cranking out code, building all the new functions needed for a robust toolkit, or at least the start of one. We still needed a name…

One Response to Why Spry? Part 2

  1. Jonas Flint says:

    ohh, can’t ignore standards and validation…. this would cut out adoption from a lot of users…Where can I post a wishlist for new dreamweaver features.