W3C home > Mailing lists > Public > public-qa-dev@w3.org > October 2005

Re: Checklink AJAX hack

From: Ville Skyttä <ville.skytta@iki.fi>
Date: Thu, 27 Oct 2005 08:58:13 +0300
To: QA Dev <public-qa-dev@w3.org>
Message-Id: <1130392693.4920.297.camel@localhost.localdomain>

On Thu, 2005-10-27 at 13:34 +0900, olivier Thereaux wrote:

> Hmm, cool. Very interesting, thanks for sending this in. Does not  
> work well with safari, but for a one-day hack, it's working quite  
> superbly on every other browser I tried.

Hm.  It works pretty decently with Konqueror 3.4.2, so I imagine it
wouldn't require much hacking to get it to work better with Safari too.

> - give people a "copy this code" to paste into their page. The code  
> would basically be a <script src="..."></script>. There could be a  
> "check links" button that would trigger checking all links (similar  
> in a way to how the "valid foo" icons point to check?uri=referer.
> - the script could change the look of the links (via color-coded  
> background around the links themselves, or document.write() a report  
> <div> in the current page
> - etc.

Yes, these were things that I initially thought the hack would do.  But
there's one major obstacle: the asynchronous background HTTP requests
can only be made to the same hostname/port where the document in
question was loaded from.  Browsers' security settings don't allow them
to hit elsewhere, so the above functionality would be pretty limited.

I suppose there would be a way around that somehow (hard?), but I didn't
bother finding out, and that's why this hack loads a page from qa-dev,
and hits grab.pl on qa-dev once for each link (!).  That's a simple
"proxy" script that does the actual fetching of a given URL and puts
results in a couple of X-* HTTP headers which are then extracted by
client-side JavaScript.

> Now, coming back to the original idea of an "ajax checklink", it  
> sounds interesting and is definitely titillating in terms of UI, and  
> I think we could look into client-side scripting as an alternative to  
> our "this is slow" UI issues. However, I suggest being cautious about  
> the idea of moving to ecma/javascript features that we are used to  
> handle with perl: as far as I can tell, client-side scripting is a  
> massive pain to make really cross-platform, and the lack of  
> programming tools make it hard to maintain too.

Received on Thursday, 27 October 2005 05:58:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:54:50 UTC