"A proposal for making AJAX crawlable" squats in URI space, doesn't follow the principle of least power

I recently discovered google's proposal[1] via a criticism[2].
I think the criticism is well argued:

"Google’s proposal is to define a convention for URLs that contain state
information in the anchor and to define a convention for retrieving the
canonical, indexable contents of the an URL with such an anchor tag.
First let me dismiss the suggestion that you make a headless browser
available over HTTP to render your AJAX pages to HTML out of hand. If
it’s so easy for HtmlUnit to render your AJAX to HTML, surely Google can
do it. And basically offering HtmlUnit as a web service on your server
doesn’t sound that secure or scalable to me.

The bigger question is that if your solution requires the server to be
able to serve the correct HTML for any state, would you come up with the
same solution as Google? There is a simple, straight-forward solution
that works today and is used on sites all over the internet. If the
content you serve includes the static, non AJAX URLs in anchor HREFs but
uses JS click handlers to do AJAX loads then crawlers can scrape all of
your pages, users of modern browsers get the full shiny experience and
users on old mobile browsers that don’t support JS get to work for
free!"

I bookmarked it under
http://delicious.com/connolly/web+architecture+disagree

tracker, please bookmark it under
  webApplicationState-60 ISSUE-60

While we're considering the form of work on Web Applications
Architecture at the meeting next week, I suggest we look at
this as an example of what is _not_ consistent with
a good architecture.

[1]
http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html
[2] http://ianloic.com/2009/10/08/not-solving-the-wrong-problem/
[3] http://www.w3.org/2001/tag/2009/12/08-agenda#Applicatio



Hmm... the principle of least power doesn't seem to have
an issue... so I guess a back-link will have to do.
 http://www.w3.org/2001/tag/doc/leastPower.html


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Thursday, 3 December 2009 16:59:15 UTC