Re: Client-side redirection is timed input

At 06:13 PM 2001-01-25 -0500, Ian Jacobs wrote:
>Greg Lowney wrote:
>> 
>> In today's conference call we discussed whether checkpoint 3.6 ("Allow
>> configuration so that an author-specified 'client-side redirect'...does not
>> change content except on explicit user request") should be raised from
>> priority 2 to priority 1.
>> 
>> It seems to me that a user agent must already allow the user to override
the
>> timing of auto-redirection in order to comply with checkpoint 2.2. The
>> latter reads "For a presentation that requires user input within a
specified
>> time interval controlled by the user agent, allow the user to configure the
>> user agent to pause the presentation automatically and await user input
>> before proceeding", and it is priority 1.
>> 
>> In fact, it seems that client-side redirection is in fact just an
example of
>> "a presentation that requires user input within a specified time interval
>> controlled by the user agent", and therefore 3.6 is just a special case of,
>> and therefore redundant to, checkpoint 2.2.
>
>My understanding is that a client-side redirect requires no user
>input; after a time-delay, the user agent GETs a new page. Sometimes,
>the content that is available during the time-delay allows the user to
>manually GET the new content. But the user's input is not required
>to trigger the GET.
>

What is the actual technology for "client-side redirect"?  One I am aware
of is
emulating redirection with a refresh pointing to a new URL as the source for
the refresh.

I presume that there are scripting ways to do this as well.

The terminology "server side" and "client side" may not be the clearest
language available, at least in terms of as-built structure of the
technology. 
To me "server side" is a colloquial synonym for "in the HTTP layer" and
"client
side" is a synonym for  "in the HTTP and script execution layer."

Where am I going with this?  There is a question whether "client-side
redirects" can be distinguished from "client-side refresh" by the user agent. 
Certainly in the common case I mentioned above, the redirect is accomplished
using the refresh mechanism.  So we don't need to have separate checkpoints
for
two things the user agent can't tell apart. 

Since we have excepted instantaneous refreshes, where the guidelines trust the
author that the first page is not worth reading if your browser processes the
refresh and redirects you to the second page, then it is not clear that there
is anything for Checkpoint 2.6 to address.  So-called "client-side redirects"
are going to be either a) instantaneous, in which case we wink at them, b)
refreshes, in which case they are covered in 2.7, or c) actions from scripts,
in which case I believe that they are covered by a) or b) regardless, if we
can
do anything about them.

With the possible exception of a zero-delay refresh which the browser may be
allowed to "just do," any "load new resource" action which arises from a
system-generated event such as a timeout, and not by an explicit user request
for such a context change, is what has to be trappable [forced to require
confirmation] if the user wishes to configure the browser to do so.

The "it breaks the 'back' function" problem is a genuine problem, but this is
the subject of the content guideline to use HTTP redirects and not HTML
refresh
to accomplish redirects.  I am not sure we want to ask the browsers to repair
'back' in this instance when the problem is broken content and the
preponderance of browsers support a history which affords a reasonably
understandable workaround.

Al

> - Ian
> 
>> Is 3.6 valuable as a separate checkpoint, or should it be just one of the
>> examples given in the Note or Techniques for 2.2?
>> 
>>         Thanks,
>>         Greg
>
>-- 
>Ian Jacobs (jacobs@w3.org)  
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783
>

Received on Friday, 26 January 2001 15:27:44 UTC