- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Sun, 4 Jul 2004 08:42:16 +0100 (BST)
- To: w3c-wai-ig@w3.org
> - if the cookie is set, do a reload via javascript (not META) after a > set timeout period Firstly you meant (the non-standard) HTTP Refresh header, not META; Refresh works as a real HTTP header including on non-HTML resources, at least for major browsers. Conceptually it only works in META because it works as a real header. Secondly, there is no reason that I can see for involving scripting here (except possibly as a counter counter measure for users who turn off the Refresh mechanism - but such counter counter measures are likely to be rapidly adopted by the abusers if the counter measure is adopted by users). There is not strong case for cookies either, except to allow an anonymous user to use the main URL on a later visit but have their preference remembered. Within a session, two alternative URLs would be as good. Generally, though, HTML is not well suited for this sort of periodic update, even with some of the features in IE that allow the update to be done without he screen jumping. There might be a legitimate case for scripting here to create a client side application that fetches just the data, although non-script alternatives must be provided. Note that NS4 would require misuse of form fields to avoid a complete regeneration of the display. Also, pages that auto-update like this should never contain any form controls, with the possible exception of submit buttons, as one of the most irritating features about this sort of technique is that it can catch you out when you are halfway through changing parameters (the typical case is that you are changing filtering paramters). Even links and submit buttons are vulnerable, but not as vulnerable as multi-step processes.
Received on Sunday, 4 July 2004 03:42:18 UTC