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

> [Original Message]
> From: David Woolley <david@djwhome.demon.co.uk>
>
> > The problem with redirection is that as http-equiv handles it,
>
> This use of http-equiv (although direct Refresh HTTP headers actually
> work) is specifically outlawed in the current HTML specifications (4.01),
> although largely ignored, as most people don't read them.  Refresh,
> itself, is a Netscape proprietary extension to HTTP.
>
> It's outlawed in non-normative text as the HTML specification doesn't
> specify Refresh normatively in the first place.

Nope, it's not outlawed by the HTML 4.01 spec.
The note says "should not" not "must not" which means that in
an ideal world, people would use only server-side redirects.
The problem is that not all document authors have access to
the server-side redirect mechanism that exists on their server
(assuming it exists in the first place). And even if they do have
access, they have to learn how to do it. Since Refresh does not
need much effort to learn and even less to use, is it any surprise
that it is used?  All a deliberate choice to not include some
redirection mechanism in XHTML2 will accomplish is to cause
authors who currently use <meta http-equiv="Refresh" /> to
continue to use pre-XHTML 2.0 pages to accomplish that task
even if they use XHTML 2 for everything else.

In designing XHTML2 we shouldn't get so caught up in
designing a best that will never get used that we fail to
design a better that will get used.

As for my proposal, it differs from Refresh in two significant ways.
1) It does not have a mechanism for specifying a delay before
    going to the other resource.
 2) It allows the URL that it goes to to differ for diverse # targets.

It certainly would be feasible for the redirection specified by
my proposal to be done server-side since it there is no potential
delay,  Ideally, the <body>, if any, would not be displayed where
a redirection is specified. and scripts would not be processed
client-side., even if the redirection were handled client-side
instead of the more advantageous case of server-side.

Received on Wednesday, 12 November 2003 13:59:32 UTC