Re: Client-side redirection is timed input

Hello,

Al's comments below suggest that in practice, a user agent
may not be able to distinguish a client-side redirect from
a client-side refresh, and therefore we may not need two
checkpoints.

Some comments, questions, and musings:

 1) Can the UA distinguish redirects and refreshes encoded with
    the META element (refer to Netscape's documentation of this [1])?
    I think the answer is yes. If document designated by 
    URL "A "contains a META element that also has URL "A", this would
    most probably be a refresh, not a redirect. Also, if the 
    time interval is zero, then it's most probably a redirect,
    not a refresh.

    However, there is no guarantee that a page that is refreshed
    once will continue to be refreshed in the future. Thus, you
    can't assume, by looking at the META markup, that "this page
    will be infinitely refreshed at the current rate."
   
    [1] http://home.netscape.com/assist/net_sites/pushpull.html

 2) Should authors use client-side redirects? No. 
    Should authors use client-side refreshes? Maybe. There may
    be other methods I don't know about.

    Even if we end up with one checkpoint, I think it's worthwhile
    to distinguish these semantics rather than generalize the
    requirement to "allow the user to stop automatic content updates
    and to update the content manually instead". I'd rather
    be specific here, unless people can show other techniques
    that cause similar effects that we should be addressing.

 3) Should the user agent be doing anything different in the
    two cases? Maybe.

    * How should "back" work in the redirect case? If the
      redirect were done by the server, I think that the back
      behavior should be different in the case of a temporary
      v. a permanent redirect. The back button should skip
      a permanently redirected page, and should not skip
      a temporarily redirected page. I don't know that this
      distinction is made with client-side redirects. I think that
      pages redirected after t=0 should be skipped by back, while
      others should not. 

    * How should back work in the refresh case? If page A is
      refreshed 8 times, should the back button take me back through
      the previous instances of the page, or should it take me
      to the page I visited prior to reaching A?

    * We require the user agent to alert the user that new content
      is available (to be retrieved manually). I think it would
      be helpful to send different messages to the user in the
      two cases:

       Refresh case: "You should reload because fresh data 
                      is available."

       Reload case: "You should reload because you shouldn't
                     be looking at the page you are looking at."

       I think setting different expectations would probably orient
       the user. 

  4) At yesterday's call we distinguished the priorities of the
     two cases based on semantics alone. We argued that in the
     redirect case, it was only P2 to allow manual control since
     the author's intent was that the user not view that page
     anyway. And it was P1 for refresh since the user was meant
     to view the content.

Conclusion:

  - I think that we need to distinguish the two semantics and
    I don't think it hurts to do so in two different checkpoints.
  
  - I think that in practice it is possible to distinguish the
    two META element cases that we are focusing on.

 - Ian
    
Previous discussion on this topic:

 9 May 2000 history of these two checkpoints:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0332.html

 9 May 2000 teleconf discussion:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0327.html

 Comments from Al based on Nir Dagan comments:
   http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0412.html


Al wrote:
> 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
> >

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Friday, 26 January 2001 20:57:59 UTC