Re: FW: Re: [XHTML2] Linktype 'redirect' and an idea for a finer grained version of it

> As for my proposal, it differs from Refresh in two significant ways.

I don't, unfortunately, have time to write up all my thoughts on this
at the moment, but, if one accepts there is a use case for HTML based
redirects (as against server side redirects and HTTP mediated client
side redirects) and then that there was a case for fragment based
redirects, I would suggest that:

- user agents be mandated not to redirect based on any element that
would not be visible in an unstyled and unscripted interpretation of the
document (and as far as possible to extend this to styled and scripted
interpretation).  This is to ensure that anyone given (or saving) a
reference to the whole page for the purpose of accessing a redirected
fragment should not just find that the fragment had disappeared (even
if the document were viewed in hard copy).  This is a result of similar
principles to those that require that a client side HTTP mediated 
redirect should include a payload describing the redirection in
human readable terms.  It would mean that link was not an acceptable
vehicle for such redirections.

- it would be necessary to first define the browser history list (back
button) mechanism in a generic way (e.g. crawlers won't normally 
support this function) and then define how successful (no trace on
history list) and unsuccessful redirections (the page with the 
redirection should be made visible by some means or other and possibly
any side effects of the page redirected to should be undone).

Received on Thursday, 13 November 2003 02:20:54 UTC