CSS: The Tech Ajax Forgot

…. Wherein our protaganist awakes to the power of CSS …

CSS is as important to Ajax as Asynchrony and XMLHttpRequest. Which is to say, it’s very useful, even though it’s not essential. Due to an accident of the English language, JJG’s creative mind, and the propensity of certain terms to rise to buzzdom, it doesn’t explicitly feature in “A.J.A.X.”. However, the original Ajax article certainly spells out the importance of CSS matters – the first of 5 things “Ajax incorporates” is:

standards-based presentation using XHTML and CSS;

And in the FAQ below that:

Why did you feel the need to give this a name? A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.

Myself, I missed the significance of CSS for a long time. I considered it mostly a useful engineering concept – to cut down on markup – and a way to make things prettier. As I’ve spent more time creating rich web apps, I’ve come to appreciate how powerful it is, and how important it is. Not just from a layout perspective, but as a key piece of an overall architecture. With CSS, you can change element visibilty, you can create transparent popups, you can load images faster (using backgroundPosition; see Sprite pattern). You can make Flickr-style annotation boxes without a single line of Javascript. You can also support graceful degradation, e.g. keeping an Ajax-related element hidden until the onload script makes it visible (although degrading gracefully for someone not using CSS is another problem altogether). So CSS goes well beyond appearance and even beyond keeping DRY.

Furthermore, scripting with CSS is the best thing since sliced sashimi! At first, I wondered what all the hype was about, but now, I have to say I’d find it hard to go back. I’m using Prototype with the $$ speedup patch and it seems to hold up fine from a performance perspective. It’s becoming a standard idiom to loop through each element, using the selector, when the document loads (to do some sort of initialisation).

As one example of selector coolness, here’s a library function to clear all input elements, also combining the pleasance of Prototype Rubyish iteration.


  1. function clearInputs(cssSelector) {
  2.   $$(cssSelector + " input").each(function(el) {
  3.      el.disabled = false;
  4.      if (el.type=="text") { ele.value = ""; }
  5.      if (el.type=="checkbox") { el.checked = false; }
  6.   });
  7.   $$(cssSelector + " textarea").each(function(el) { el.disabled = false; el.value = ""; } );
  8. }

If I want to clear all inputs under submitForm, I call clearInputs("#submitForm"). If I want to clear all inputs on the page, I call clearInputs("body"). If I want to clear all inputs inside advertising portlets, I call clearInputs(".portlets .advert"). Bruce Eckel once said (something like: “It’s syntactic sugar, and syntactic sugar is good.” He’s also spoken about how the average programmer codes X lines per day (canonically ten, but the number doesn’t matter). Any syntactic sugar that reduces lines, will probably let you achieve more. Not to say that the number of lines is really fixed, but there’s definitely going to be an impact if you’re writing a big block instead of a single line. So, yeah, CSS Selectors + Rubyish Iteration, via Prototype, is a big win if you value concise code.

To sum up, I’ve found CSS to be a highly valuable skill for modern web development, and for three reasons:

  1. The obvious reason that knowing CSS helps make your pages pretty, usable, accessible, etc.
  2. CSS manipulation is important for managing the interaction in rich web apps, including graceful degradation.
  3. CSS Selector Scripting is the new Dependency Injection!

Ajax Functionality and Usability Patterns – Podcast 3 of 4: Visual Effects

This is the third in the four-part series on Ajax functionality and usability patterns (Book: Part 4, pp 327-530). An audio discussion of visual effects is ideally short and sweet, so this podcast is but 13 minutes long.

This 13-minute podcast covers ten patterns of Ajax Architecture (Book: Chapter 16, pp 445-472):

How Much Docs?

Nate’s talking about functional specs.

How much doco happens on a project is one part opinion and one part “what do you want to optimise for?”. I generally find there’s a dichotomy in attitude to software documentation.

1. Definitive (aka normative, exhaustive, complete, bureaucratic, rigourous, formal). The ideal here is that everything should be covered in documentation – the docs are a snapshot of every activity, plan, and state of the project. The aim is: (a) to let you carry on unhindered if “(stakeholder/worker) is run over by a bus” for all instances of (stakeholder/worker); (b) affect payments and provide legal evidence/cover. 2. Informative (aka agile, pragmatic, informal, half-hearted). Use docs pragmatically, to help explore ideas, reach consensus, remember what we said, etc. You cannot reconstruct a project from docs like this – if everyone is “run over by a bus” at the same time, there will be a delay and a subsequent divergence in the project direction.

That’s a clear distinction – in the Informative mindset, the docs are only there to reach a better quality result; in the Definitive mindset, we’re compromising some productivity for the sake of risk management (both (a) at a tactical level, i.e. if someone leaves; and (b) at a strategic level, i.e. upper management can theoretically be comfortable about how much is exposed and how much they’ll get back as a penalty if things slow down, etc.).

Both Definitive and Informative have a range of approaches. In particular, Informative use of docs can range from none at all, up to a project resembling a Definitive project, but when you look closely, the docs are lightweight and only subject to informal reviews rather than full-on inspections and audits. They may also the use of less conventional “documentation”:

  • Whiteboards
  • Post-it notes
  • Flashcards
  • Wikis and blogs.

As an agile proponent, I’d generally favour the Informative approach, but software isn’t developed in a vacuum. Organisations understandably want to be reassured about what gets delivered, which pushes them to rely on Definitive methods. The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

There’s obviously no one solution, but one essential ingredient comes from multi-talented people. Too often, requirements are penned by business people on the assumption that software developers are left playing with their compilers. That’s changed a lot over the past five years, and organisations will do well when they hire business people who have an interest and competency with software, and software developers (fast becoming the majority) who can empathise with the business’s needs and are actually literate as well.

(I hope it doesn’t go unnoticed that Software As She’s Developed has actually posted about software development. That’s so ’04.)

How ‘Bout Those Radiobuttons?

I’m all for Web 3.0 gadgetry in the browser, but how about some JS love for those ancient radio controls. It should be easy and portable to: * Get the current value of a radio group, without looping through each radiobutton to find the one that’s checked! * Catch onchange events (no luck with IE).

Right now, it’s not.

Those are some humble wishes – hopefully they’ll take priority over the grand plans for graphics, rich controls, and the all-powerful built-in physics engine.

Congrats to the Touchstone Team

Props to the Touchstone team for receiving funding, getting a glowing TechCrunch reception and generally heading in a positive direction.

Touchstone is an “Attention Management Engine” – it’s a combo of Growl, RSS aggregator, and Widget system. The trick is that it tries to be intelligent about what it notifies you, and how it does it. Critical messages appear in your cursor trail(!), less critical in a ticker or a “toast” systray popup.

For most of us, Moore’s Law ceased to be useful about five-eight years ago. Unless you’re playing the latest 3D games, you’re still doing the same things you were doing when CPUs was 20 times slower and storage was 20 times smaller. Other than keeping more windows and browser tabs open (granted, that’s nice), modern apps and OS’s do precious little with those extra CPU cycles. Spotlight, though a usability failure, shows Apple at least gets it – I think the idea was to accumulate info about your hard drive during idle momnts. (The reality is different.)

Touchstone gets it too. I think we’ll see attention management engines like this get more intelligent as time goes on. But at the same time, Touchstone does let you set your own preferences, and this is key for intelligent systems. A hybrid approach ,where the computer monitors and builds up info about the user’s preferences, whims, and so on, but also exposes that model to the user and allows them to tweak it. This hybrid approach is encapsulated in the story for Lazy Registration:

It’s Saturday afternoon, and Stuart is busy planning the evening’s activities. He visits a band listings website, where he clicks on a map to zoom into his local area. Even though he’s never visited the site before, a profile is already being constructed, which he can see on the top of the site. At this stage, the profile guesses at his location based on his actions so far. As he browses some of the jazz bands, the profile starts to show an increasing preference for jazz bands, and some of the ads reflect that. Since the jazz thing is a one-off idea, he goes in to his profile and tweaks some of those genre preferences, but leaves the location alone as that was correctly guessed. Finally, he decides to make a booking, at which point he establishes a password for future access to the same profile and also his address, which is posted back to the profile.

Anyway, well done Chris, Ashley, and the Touchstone team! When I say that some VC makes sense and some doesn’t, this is exactly the kind of situation where it makes sense to inject funds and build something big. The Touchstone team needs to reach out to developers to build Touchstone adaptors (I really think they should be called widgets, even though it’s not a widget engine) and build awareness among users. Right now, developers must use .Net, so hopefully they’ll expand their adpator platform to be more like Dashboard/Yahoo/MS widgets etc, allowing development in HTML/JS. Right now, Touchstone is Windows-only. There’s no standard like Growl on Windows, and Touchstone has every chance of becoming that standard – it would allow Growlish behaviour and a whole lot more.

The Wiki Twitch

I can feel a case of the Wiki Twitch coming on …

Victims of the Wiki Twitch have a perfectionist tendency which causes them to optimise content they come across, for the benefit of others and for reasons of “enlightened selfishness” – the motivation to improve what they will likely read again in the future. Many of these Wiki Twitchers have spent hundreds of hours in front of a computer screen, browsing encyclopaedias, reading community-created theories, and some are mad enough to write entire books inside a wiki. The twitch may begin when using these systems, but after some time, Wiki Twitchers fail to differentiate between websites that are wikis and those that are static, leading to a general desire to edit all content, even that which is not open for editing.

When content is hosted on editable wikis, the Wiki Twitch can actually promote a general feeling of well-being. But outside that realm, on the Static Web, it can lead to ultimately unsuccessful gestures – “Wiki Twitches” – towards a non-existent Edit button. Over 99% of the web remains ineditable at this time, leading to frequent delusions of editability.

The situation may be different in the future. Some younger Wiki Twitchers will never know what it’s like to pick up a static encyclopaedia and experience the feeling that it’s immutable. They are increasingly growing up to know a world where everything they can see can be changed by consensus.

A further trend is revealed by the increased interest in Second Life and other Massive Multi Player Online Role Playing Games (MMORPGs). Its only a matter of time before the “everything is editable” delusion of the Wiki Twitch extends to real-world objects.

A significant sub-population of Wiki Twitchers are programmers who have succumbed to the related phenomenon known as Test Infection. The refactoring bug is the cause of this infection, and, though primarily involved in a symbiotic relationship with software code, it has a natural affinity with wiki content.

Individuals suffering Wiki Twitch are advised to spend more time inside the Editable Web. If pain persists, install an appropriate annotation tool, such as Diigo or WizLite.

Ajax Books Page

Via the APress mailing list, I just discovered no less than six new Ajax books are coming out, covering Ajax and .Net/ Ajax and Java (by Nate and Ryan, authors of Foundations of Ajax), etc. I was gonna post them here, but I thought I may as well add an Ajax Books page to the wiki, so here’s the list of Ajax Books … publishers/authors/fans are you listening? Please add any books I’ve missed out (there are plenty of those) and also feel free to link to Amazon and other stores.

The current version of http://ajaxpatterns.org/Books looks like this:

General Ajax and Introductory

Beginning JavaScript(tm) with DOM Scripting and Ajax: From Novice to Professional

  • By Christian Heilmann
  • APress

Ajax for Dummies

  • By Steve Holzner
  • Dummies

Ajax Hacks

  • By Bruce Perry
  • O’Reilly

Ajax Headrush

  • By Brett McLaughlin
  • O’Reilly

Ajax In Action

  • By David Crane, Eric Pascarello, Darren James
  • Manning

Foundations of Ajax

  • By Ryan Asleson and Nate Schutta
  • APress

Pragmatic Ajax

  • By Justin Gehtland, Ben Galbraith, Dion Almaer
  • Pragmatic Bookshelf

Professional Ajax

  • By Nicholas C. Zakas, Jeremy McPeak, Joe Fawcett
  • Wrox


(Based on this website!) Ajax Design Patterns

  • By Michael Mahemoff
  • O’Reilly

Ajax Patterns and Best Practices

  • By Christian Gross
  • APress

Ajax-Related Technologies (Javascript etc)

Beginning XML with DOM and Ajax: From Novice to Professional

  • By Sas Jacobs
  • APress


Foundations of Atlas: Rapid Ajax Development with ASP.NET 2.0

  • By Laurence Moroney
  • Apress

Pro Ajax and the .NET 2.0 Platform

  • By Daniel Woolston
  • APress


Pro Ajax and Java(tm) Frameworks

  • By Ryan Asleson and Nate Schutta
  • APress

Practical Ajax Projects and Java(tm) Technology

  • By Frank Zammetti
  • APress

Ajax Functionality and Usability Patterns – Podcast 2 of 4: Ajax Page Architecture

This is the second in the four-part series on Ajax functionality and usability patterns (Book: Part 4, pp 327-530).

The guest for this week is Dave Johnson of Nitobi (the Ajax component developers formerly known as E-Business Applications), widget guru and author of the upcoming Enterprise Ajax book. Dave helps me walk through the patterns and offers plenty of great insights along the way. We mention Dave’s recent presentation a couple of times; here’s the PDF.

This 54-minute podcast covers ten patterns of Ajax Architecture (Book: Chapter 15, pp 389-444):

Web 2.0: What Happened to Organic Growth???

Another day, another round of VC. From TechCrunch this week:

Online social network Multiply has closed a Series A funding round with $5 million from Transcosmos and $1 million from the company’s founders. Multiply is a service that filters all networking functions, from highlighted users to visible tag clouds, through a proximity filter with a slider. In other words, users determine whether they want to view information about people just on their contacts list, who are friends of a friend, etc.

And this from last month (via The Medici Effect):

Wine.com has become the most stubborn dot.com hangover ever.

The San Francisco online wine retailer, which depending on how you count is now on around its seventh reincarnation since launching in the 1990s, will announce tomorrow that it has raised $12 million in new venture capital from New York-based Baker Capital.


p>Technorati also announced a new $7 million round this week. Hardly significant for a company people speculated to have been talking about a billion-dollar acquisition a while ago, but still, it makes you wonder – if the organic growth model really works, how can a Web 2.0 poster-child still need a cash injection after being live and successful for over 2 years?

Cameron Reilly I believe had planned to go organic with ThePodcastNetwork, but he reported this week that he started to opt for the acquisition path instead.

Funding last week for some hotel version of myspace I’ve never heard of that wants to expand to Japan; Rumours of upcoming funding for HuffingtonPost; I could go on.

VC is all good if you know what you’re gonna do with the cash, but what happened to organic growth? You know, all the arguments about “everything’s cheap now” (open-source argument), “people are willing to pay for virtual goods” (37S/Flickr argument), “avoid overplanning” (agile argument), “Adsense rocks” (plentyoffish argument), “VCs burned us in 2000” (learning from history argument), “we can outsource development” (naieve naieve argument).

Am I missing something? Has Web 2.0 entered a new phase where VC is now the thing to do? Did the organic growth model just fade away?

Ajax Functionality and Usability Patterns – Podcast 1 of 4: Widgets of the Web

And so, a new series begins, based on the Ajax functionality and usability patterns (Book: Part 4, pp 327-530). We’ve already looked at the technical details, now we’re looking at what Ajax can do for users and how to implement these features.

I’m asking guests to join me for most of the remaining Ajax Pattern podcasts. Seeing patterns from someone else’s perspsective will make the discussion richer and hopefully cover more questions you might have as you’re listening to the podcast. The guest for this week is Andre Charland of E-Business Applications, widget guru and author of the upcoming Enterprise Ajax book.

This 83-minute podcast covers nine patterns of Ajax widgets: