- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 08 Mar 2001 12:07:25 -0500
- To: Charles McCathieNevile <charles@w3.org>
- CC: w3c-wai-ua@w3.org
Charles McCathieNevile wrote: > > My proposal is for _A_ technique for doing this in a really cool and helpful > way (i.e. goes way beyond the P1 requirement of the checkpoint). That's why I > proposed it as a technique. Yes, I understand that and can add it to the techs doc. > I explicitly suggested not changing the checkpoint. I still don't see how the > checkpoint fails in any way to cover your requirements a and b as written, > and that the proposed change would preclude the technique that I have > suggested. Ok, I withdraw my proposal. - Ian > Therefore I object to changing the checkpoint in the manner foreshadowed. > > Charles > > On Thu, 8 Mar 2001, Ian Jacobs wrote: > > Summarizing: > > - The proposal was "don't do the refresh" > - Charles says that's too restrictive, since the UA might > do the refresh and provide the user with a useful diff > on demand. > > I still support the proposed change for the following reason: > > a) The user need is stability. > b) The minimal requirement is "don't make the change unless > the user says it's ok" > c) Charles' proposal goes beyond the minimal requirement that > I believe the checkpoint was meant to accomplish. > > (It would seem that the proposed change is not editorial.) > > I propose therefore that the minimal requirement is > "don't do the change unless the user says ok" and that the > checkpoint be changed to reflect that. > > The user agent can do more (e.g., provide useful diffs on demand), > but I don't believe that's ever been the intention of the > checkpoint. > > - Ian > > Charles McCathieNevile wrote: > > > > OK... > > > > My assumptions: > > The point of the checkpoint is to keep the page stable if the user > > desires. What the user agent does behind the scenes has more or less no > > impact for accessibility. > > > > Where there are in fact changes being made to the page, it would be helpful > > for a suer to know what they are to some level of detail lower than "the page > > changed (somewhere, perhaps)". > > > > My conclusions (I figure we all have the same information to work on :): > > The existing wording meets the accessibility requirement. > > > > Aaron's potential interpetation of it is a valid interpretation. > > > > Aaron's approach gives rise to the following technique for doing something > > even better than just not doing the refresh, viz: > > > > Get the new version and find out what, if anything, has changed in it > > (simple markup-aware diff). Store that information, sequentially (a la a > > markup-aware version of CVSWeb, and Aaron probably has access to such). > > Allow the user to view that information at any time, as a seperate function > > to doing the update. > > This allows the user to work out what is going on in the original page, and > > then just find out what changes. (It is probably helpful to know if nothing > > changes, too). A couple of iterations of this should be helpful in deciding > > whether to turn off auto-configuration, and read changes from this function > > as desired, or turn it back on. > > > > A working example of sorts: > > > > Cricinfo - http://www.cricinfo.org - provides real-time (more or less) score > > and commentary of cricket matches from around the world. If I use a standard > > scoreboard, it auto-refreshes frequently, but it only changes a few parts of > > the page - the current batsmen/bowlers, the current score, and the most > > recent commentary in full and abbreviated form. The scoreboard for batsmen > > who are already out, and for previous innings, remains unchanged. > > > > With a system like I have described, I could look at the scoreboard, and look > > at the changes. This would enable me to find out which bits are being > > changed, so I know which bits to look at again when the page is updated, and > > which bits to ignore. Or I could decide to stop the autorefresh, and do it > > manually when I want. (I often do this, and there is an option on the site to > > get a version which does it too). Or I could start from a known page, and > > read the changes made in subsequent (unseen) versions - updated commentary, > > or scores... > > > > Cheers > > > > Charles > > > > On Thu, 8 Mar 2001, Ian Jacobs wrote: > > > > Charles McCathieNevile wrote: > > > > > > Yes, I object. I am proposing to do something different with the same > > > information, for the reasons given. > > > > > > Also becuase I think it places operational constraints on the User agent that > > > may be in line with normal implementation methods but are not actually > > > enhancing the accessibility of the user agent, and may detract from it. > > > > I'm sorry, I simply don't understand your point I guess. > > I thought the checkpoint has tried to say "Don't do automatic > > refreshes". Aaron said that wasn't clear. The proposed rewrite is > > supposed to be clearer. > > > > I don't understand what the operational constraints you are talking > > about are. > > > > I also didn't understand your technique. > > > > Could you expound further on the source of your objection? > > My goal here, mind you, is only editorial clarification, not > > alignment with existing implementations, etc. > > > > - Ian > > > > > cheers > > > > > > Charles > > > > > > On Thu, 8 Mar 2001, Ian Jacobs wrote: > > > > > > Charles McCathieNevile wrote: > > > > > > > > I don't see that there is a problem using the method Aaron suggested. It > > > > would enable a user agent to seperately queue the changes to a document that > > > > gets updated on the fly, which seems like a good thing since they could be > > > > offered to the user who had asked for a page to stay still, as a seperate > > > > item. It might be helpful to have this available, and I can't see that it > > > > breaks anything we need. > > > > > > > > So I would propose to instead add this as a technique. > > > > > > Would you object to the editorial change? > > > > > > _ Ian > > > > > > > Reference document 24 Feb 2001 draft [1]. > > > > > > > > 1) Checkpoints 3.5/3.5 > > > > > > > > 3.5 Allow configuration so that client-side content refreshes > > > > (i.e., those initiated by the user agent, not the server) > > > > do not change content except on explicit user request. > > > > > > > > Aaron suggested that this might be interpreted as meaning > > > > "compare and see if the refresh changed the content or not". > > > > > > > > Proposed change: > > > > > > > > Allow configuration so that the user agent does not > > > > perform client-side content refreshes (i.e., those > > > > initiated by the user agent, not the server) > > > > except on explicit user request. > > > > > > > > I propose the same type of change to checkpoint 3.6: > > > > > > > > [snip] > > > > > > -- > > > Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 > > > W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 > > > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia > > > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France) > > > > -- > > Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 > > W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 > > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia > > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France) > > -- > Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 > W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France) -- Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783
Received on Thursday, 8 March 2001 12:07:27 UTC