I don’t GET the problem

So there’s been a lot of blogosphere reverberation over the Google Web Accelerator which follows every link on every page you visit in order to speed up your browsing experience, including links such as “delete this post,” and now everyone is talking about how web applications should be written not to allow unsafe operations from GET requests, mere links, and that such operations should be done only by POST requests. The GET mess has a good roundup of all the handwringing that has been posted, and I won’t duplicate it all here.

David Heinemeier Hansson has a plan for patching things up for now that involves a facility which masks non-idempotent links behind javascript: URLs. Phil Ringnalda comments that this is all just so designers can continue to put the functionality of buttons behind links because it gives them greater control over appearance. I think the issue is only partly one of stylability (more on that in a second), and while web design that breaks established UI conventions sucks, using links for destructive actions is quite okay so long as a click pops up a confirmation.

The problem is that no one has been doing this correctly. Clients which do not understand Javascript for whatever reason, such as the GWA but also limited capability browsers on a mobile device, do not get the benefit of a confirmation dialog. Hiding the functionality of the link-as-button behind a javascript: URL prevents them from accidentally causing harm, but that can hardly be called a sustainable solution. Phil’s suggestion that a link titled “Launch The Nuclear Warheads” should lead to a page containing a button labelled “Launch The Nuclear Warheads” is exactly right. Unfortunately, it disregards an important reason for wanting links+Javascript: application reactiveness. Serving a page with a button incurs an extra roundtrip that makes applications tedious to use.

It is really only a small step from his good approach to what I consider the really proper solution: the same link which leads to a page with a button should also have an onclick handler attached which shows an “Are you sure?” prompt and converts the request to POST on confirmation – and that request would then be executed immediately without the intermediary page with the button. This means fewer roundtrips and a more reactive interface where supported but no trouble yet all of the functionality where not.

This isn’t any news. It’s much like the right way to do chromeless popups (put the link into a plain <a href="" target="_blank"> and attach an onclick handler for opening the chromeless popup and inhibiting the default link behaviour). It’s much like the right way to use XMLHttpRequest.

It’s called graceful degradation.

Referenced in I say graceful degradation, you say progressive enhancement.