Tag Archives: HTML

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.

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:

Favicons should ideally be easy to manipulate, as easy as manipulating the web page’s UI. (Favicons are the little website icons you see in the address bar, browser tabs, etc.) For example, a chat app like Meebo could signal that your buddy’s trying to contact you, a mail app like GMail could indicate You Have Mail!

I’ve found surprisingly little info on this – is anyone doing it? Anyway, I’ve been wanting to play around with this for a while and having recently submitted the final book draft (post pending), I finally had some spare time to play with it. Fortunately, it turns out to be perfectly feasible – it seems that Firefox and Opera both use <link> tags to determine favico, and this can be changed dynamically to satisfaction. The only gotcha is that you can’t try to be too efficient – if you reuse an existing link object and overwrite its href property, the browsers won’t pay any attention. so you simply have to remove the existing link tag and add back a new one with the new icon URL. Unfortunately, IE and Safari don’t seem to use the link technique at all – I think they just use the “favicon.ico” file. If you know of a way their icons could be dynamically manipulated, please mail me or add a comment here.

So I’ve created a library, favicon.js, that lets you manipulate favicons with a single call – changeFavicon("theIconUrl.ico");. You can also set the document title, changeFavicon("theIconUrl.ico", "Hi Everybody!"), which just sets document.title. There are a couple of demos and a brief FAQ:

Crikey!Dugg and on Delicious Popular. And, well, Ajaxian too ;-). Digg is interesting … The last time I submitted my own story to digg, it got precisely two diggs (thanks to the other guy!). This time, I didn’t bother. Is there a moral here?

New, improved, with animate(). Most people get dynamic favicons, but some people have said this whole thing is about animation, about as useful as a blink tag, etc. Okay, that kind of misses the main point, which is about notifying the user while a tab is in the background. The FAQ makes it pretty clear that animated icons was a kind of afterthought (actually, it only occurred to me after I created the cycling demo – changing according to a timer was simply the easiest way to update a background tab, since there’s no chat functionality needed or anything like that). But, you know, when a simple idea like that causes seems so wrong to some people, there’s probably wheels in it. And while I did say animated GIFs are possibly more elegant in the FAQ, it since occurred to me that it’s a bit of a hassle for the casual developer to make an animated GIF. You also get the benefit of compatibility with Opera (and maybe others?). So I’ve added an animate() method, only 8 more lines in all, that lets you cycle through a sequence of images. I expect to post it over the weekend. Mmm…Eye Candy!

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all
applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a
desktop in that the browser is driving the interaction – it
mediates all interaction between the user and server, so there
are no – or few – direct page refreshes. Similarly, there’s no
– or little – session tracking in the server, because all
relevant state can be managed inside the browser. The server
may not know about HTML at all, and just offer generic web
services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall,
but one that’s been sprinkled with Ajax here and there. For
instance, Ajax might be used to validate a form before it’s
submitted using standard form submission, or to reveal some
instructions on the page when a user requests help. An example
is Delicious, which
works fine on legacy browsers, but offers Ajax Suggestions for the many
browsers that support it.

Which will you use? The Deluxe approach suits a development team
with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally
lead to a nicer, more effective, user-interface. It also
facilitates a well-partitioned architecture, since the presentation
logic can be isolated inside the browser and the business logic
isolated in the server. However, Deluxe applications may place a
strain on the browser and network capabilities, and might not even
be possible if the browser is outdated. Ajax Lite is a better
answer for older browsers, since the Ajax features can usually be
“turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

Harry Fuecks suggests there are two types of Ajax apps: HTML++ and Client/SOA. This is something I’ve noticed too, and it cuts right across the Ajax architecture, impacting on the user-interface, the physical architecture (browser-server separation) and the abilities of the developers involved.

The “Ajax App” pattern addresses this as a decision. It’s the root pattern for the entire Ajax Patterns language (Ajax App is not yet on the AjaxPatterns wiki). As you might know, each pattern has a “Decisions” section, identifying the decisions you’ll have to make if you go with the pattern. In the case of Ajax App, a big decision is how far along the spectrum you go. I’ve termed them differently to Harry, but the distinction is essentially the same (there’s now a footnote to his article). Extract from the “Ajax Design Patterns” draft:

Will your application be “Ajax Deluxe” or “Ajax Lite”?

There are two archetypal architectures for Ajax, and all
applications lie somewhere along the spectrum between these extremities:

Ajax Deluxe

Ajax Deluxe uses Ajax to the max: applications feel similar to a
desktop in that the browser is driving the interaction – it
mediates all interaction between the user and server, so there
are no – or few – direct page refreshes. Similarly, there’s no
– or little – session tracking in the server, because all
relevant state can be managed inside the browser. The server
may not know about HTML at all, and just offer generic web
services. An example is the Ajax word processor, Writely.

Ajax Lite

An Ajax Lite App feels more like a conventional web app overall,
but one that’s been sprinkled with Ajax here and there. For
instance, Ajax might be used to validate a form before it’s
submitted using standard form submission, or to reveal some
instructions on the page when a user requests help. An example
is Delicious, which
works fine on legacy browsers, but offers Ajax Suggestions for the many
browsers that support it.

Which will you use? The Deluxe approach suits a development team
with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and it will generally
lead to a nicer, more effective, user-interface. It also
facilitates a well-partitioned architecture, since the presentation
logic can be isolated inside the browser and the business logic
isolated in the server. However, Deluxe applications may place a
strain on the browser and network capabilities, and might not even
be possible if the browser is outdated. Ajax Lite is a better
answer for older browsers, since the Ajax features can usually be
“turned off” to support graceful degradation.

Epilogue:Another nice way to say this: “Ajax Deluxe” (or Client/SOA) == “Ajax Application”, “Ajax Lite” (or HTML++) == “Ajax Website”. The “Application” versus “Website” terminology was mentioned by Craig in the latest Polymorphic Podcast, Architecting Ajax Applications. If you want to hear more about the Ajax patterns (and since I’m so slow to complete my own podcasts on the topic, but I promise it will happen eventually!), check out this podcast, which is mostly about Craig’s take on Ajax Patterns. He’s not just regurgitating the patterns either, as he offers many fresh ideas and examples.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff