Bill Burcham’s memeRocket

Douglas Crockford, purveyor of the JSONRequest spec, is cranky in a polite sort of way. He also happens to be right! Check out the video of his recent talk on The State of AJAX.

Crockford takes us through a brief history of computing reminding us, as we’ve been reminded before, that the Web interaction model is practically the same as the mainframe 3270 interaction model circa 1972.

The most potent moment in the talk however, is when he shows a shot of a mermaid rendered via a run of the mill nvidia subsystem and dryly points out “look, rounded corners”. The upshot: the 1984 Macintosh had rounded corners — browsers were obsolete from the git go and there is a huge and widening gap between what you do in a web app and what you do in a non-web one.

Oh and I’m making Crockford my Personal Hero of the Month for pointing out that not only are our web technologies based on eight-year-old standards (HTML 4.0.1, ECMAscript ed. 3, CSS 3 um… started in ‘98 and still under development) but that of those, CSS is the worst of the lot and should be replaced with urgent haste. Refreshing respite from the usual CSS love.

“Don’t take any crap.”

update: watch this space for my growing list of web standards revolutionaries:

In Fight id Proliferation I highlighted the prevalent misunderstanding of the prototype API’s insert_html, replace_html and friends that is evident both in the Prototype documentation and in Rails. Due to that misunderstanding, many of us are polluting our HTML with many more id attributes than would otherwise be necessary. In the original post I proposed a fix to Rails to remedy the situation and allow us to use CSS selectors to identify a target HTML element for the various calls. In this post I provide a workaround you can use now, while waiting for a cleaner fix.

Continue Reading »

The Safari 3 Public Beta page has a nice little navigation list in the middle: 12 reasons you’ll love Safari. It’s kind of “semantic” markup since it uses an ordered list to enumerate the choices (as opposed to e.g. a table or something). And it’s kind of separating content from presentation with its use of CSS to style the list items — including nice visual differentiation for the active (selected) item. All this is pretty standard stuff for readers of Dan Cederholm’s Web Standards Solutions. And rather than reloading the whole page on each navigation click, the site is using XMLHttpRequest to load just a small section. Again, nothing surprising here.

What is a little surprising is the page’s departure from the common practice of using anchor tags within the list items. Instead of each list item containing a hyperlink, it contains plain old text. Since there is no hyperlink, the browser won’t provide a visual cue that the item is navigable/clickable. That’s kind of ok since most designers go to pains to undo some of the cue anyway — I’m talking about eliminating underlining. The other cue — changing the cursor to the pointer image when mousing over the “active” list item, is implemented via a CSS rule. Then all that’s left is to catch the click events in JavaScript code.  Here’s the markup:

It’s a pretty design and it works really nice. On the other hand it is not an example of “unobtrusive JavaScript” or of “graceful degradation”. I am pointing this out not to be dogmatic about these things, rather to cite it as evidence of the difficulty of applying the aforementioned philosophies.  Here you have a lovely page, built by the best designers money can buy. It doesn’t get much more high profile than this. And these guys went ahead and built a page that requires JavaScript. Made me think. I hope it makes you think too.

This feels like it’s going to be a bit of a recurring theme here (see the recent Tableful Grace post). Graceful degradation with respect to JavaScript, CSS, heck even background images; separation of behavior from content; table-less layout — these are great philosophies. But the practice is riddled with subtlety and compromise. And you wouldn’t really know it from reading the short “gee look what I can do” type articles.

I’m curious to know how you feel about these new sacred cows now that we’ve had a little experience with them. For example, are you implementing whole applications with graceful degradation or only pieces of your application? If it’s the latter, are you getting any real benefit? Does graceful degradation double your testing effort?