Re: Change in Priority for new event checkpoints

i've been attempting to send this since i lost connection whilst 
preparing to send it to the list late last night/early this 
morning...

--- FORWARDED MESSAGE ---
Date: Thu, 8 Mar 2001 03:37:15 -0500 (EST)
From: "gregory j. rosmaita" <oedipus@hicom.net>
To: Jon Gunderson <jongund@uiuc.edu>
Cc: w3c-wai-ua@w3.org
Subject: Re: Change in Priority for new event checkpoints

jon wrote, in defense of dropping Checkpoint 7.X to P2, quote
> 2. This is a new requirement and was not part of any previous proposals or 
> discussions on this issue.
unquote

not so, -- when the decision to reconfigure checkpoints 7.3 and 7.4
was adopted as resolved, didn't anyone hear the loud sigh of relief 
that mickey and i (and later dave) collectively heaved?  just one of 
many collective sighs--most sighs of relief, i should add, and only 
a few of frustration--shared by the three of us during the course of 
the face2face, but each was eloquent testimony to the fact that the 
issue which inspired it, like some of the other lingering issues, 
aren't in fact "new" issues or "new" requirements at all, but key 
crucial concepts, principles, and realities which we have been 
attempting to explain to the working group as a whole for at least 
the past 2 years...

so, when the decision to reconstitute 7.3 and 7.4 into 3 checkpoints 
was made, we felt as if we had finally been able to fully 
communicate, and the working group was finally able to articulate, 
the following key concepts:

(1) the user has to be able to get to every enabled interactive element 
on/in a page/document/application;

(2) that there is a huge difference between getting to an enabled 
interactive element only to have the event associated with that 
element's event handler fire instantaneously/automatically/without 
warning or foreknowledge and the ability to query an enabled 
interactive element in order to ascertain its nature and function--as 
best can be communicated either strictly through markup, or explicitly, 
thanks to an author-defined description--BEFORE making a conscious 
decision to make a leap of faith...  there's a reason the verbs "fire" 
is metaphorically employed to describe that functionality!

(3) that, given the state-of-the-art all around, the only practical way to
accomplish this is to establish focus -- especially if there are multiple
events from which the user can choose...

and the moral of the story is: configuration is nothing but a cascade, in 
which the user gets the !important -- the user MUST be able to establish 
focus upon an enabled interactive element without causing it to fire, 
even if the author has explicitly expressed authorial intent by defining 
an automatically triggered event handler for that element, full stop 
(read: end cascade)

it doesn't mean that the author can't ultimately get what he or she 
desires, simply that, as in real life,  instant gratification isn't 
assured on the web, either...

jon also observed/argued, quote
> 3. This does not necessarily guarantee access.  We already allow people to 
> turn off scripts, so they can look at event handlers without firing them 
> with this feature at a P1 level.  This seems like a new special/limited 
> case of turning off scripts.
unquote

i could as easily cite chapter and verse to trumpet a P1 -- "Make all 
content available through the user interface" springs to mind, as well as 
the underlying tenor of the document: "first, do no harm" in relation 
to the neccessity of minimizing disorientation ....

as i've said before, suggesting that the user disable ALL scripting
support in order to avoid this PARTICULAR or ANY isolated behavior is far 
too draconian... we don't ask users to suppress background images by 
turning off all image support, do we?

decapitation is an effective cure for acne, as frank zappa pointed 
out to tipper gore some time ago, but it's hardly the most efficacious...

i vote it (remain) a P1, as it is an explicit (and necessary) requirement
until either the DOM resumes work (in collaboration or alone) on the 
suspended Views module [reference 1], or until either XBL [reference 2] 
or Spice [reference 3] is widely implemented (and if so, best in 
accordance with a public spec...  XBL has, i believe, the advantage, in 
that it's origins are in the Do It Yourself world of free source, and by 
virtue of its implementation in mozilla -- presumably, as the precursor 
for the mechanism/technology underlying a user configurable chrome/UI for 
whatever else eventually emerges from AOL/Netscape...

gregory, composing on an unstable 2400 connection
3:37am U.S. EST Thursday, March 8, 2001

References (lots of long wrapping URIs):
1. DOM Views and Formatting Module (dormant, despite ray's heroic effort)
1A. http://www.w3.org/TR/2000/WD-DOM-Level-3-Views-20001115/

2. XBL (Extensible Binding Language):
2A. Submission: http://www.w3.org/TR/xbl
2B. Submission Request: http://www.w3.org/Submission/2001/05/
2C. W3C Comment: http://www.w3.org/Submission/2001/05/Comment

3. Spice:
3A. Submission: http://www.w3.org/TR/1998/NOTE-spice-19980123.html
3B. Submission Request: http://www.w3.org/Submission/1998/03/
3C. W3C Comment: http://www.w3.org/Submission/2001/05/

---------------------------------------------------------
BORE, n.  A person who talks when you wish him to listen.
              -- Ambrose Bierce, _The Devil's Dictionary_
---------------------------------------------------------
oedipus@hicom.net
           http://www.hicom.net/~oedipus/vicug/index.html
unagi69@concentric.net
---------------------------------------------------------



-------------------
Email sent using AnyEmail from http://www.hicom.net

Received on Thursday, 8 March 2001 14:31:23 UTC