events discussion from 7 Jan 2002 WAI PF teleconf

[This is a lightly edited -- edit artifacts in square brackets [] -- extract
from the minutes of the 7 January WAI PF teleconference.  We had a discussion
to clarify the relationship between PF issues with the XML Events module and
the UA issues with DOM support.  This discussion did not purport to reach any
conclusions, but the discussion that did take place may help us be more
productive on the 17 January call.  I think that this extract brings us all
pretty much up to date on anything said there that may be significant for the
DOM support question(s). -Al]

7 Jan 2002

Participants: [this part: Al Gilman (Chair), Charles McCathieNevile, 
Jon Gunderson, Ian Jacobs (Scribe)]

[...]

-------------------------
Events: UA/DOM/XML Events
-------------------------

[...]

[refer to] UA summary:
 
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0000>http://lists
.w3.org/Archives/Public/w3c-wai-ua/2002JanMar/0000

/* IJ summarizes issues */

Questions:
1) Do we need to know that "this node" has handlers for event
    type E, or that "some node" has handlers for event type E
    that may be triggered at this node?

2) How best to describe event handlers?


CMN: You can attach handlers to documents as a whole (e.g.,
rollover highlight, also annotate an element). In the case
of Amaya, annotation is part of the client software; it's not
attached to the page itself. There's another part of W3C's
Annotea work where you can put javascript in pages to add
or delete annotations.

CMN: The interesting bit is that the UAWG is saying "We want
to know what's explicitly attached to the current node." This
isn't what the (non-disabled) user perceives; the user perceives
events happening.

JG: Current requirement is to be able to fire an event handler
when explicitly attached to a node N. Implicit is that you
need to know that there's a handler at the node N.

AG: If the requirement is that whatever you can do with the mouse
you can do some other way, and you need to know when this is
applicable, then the more inclusive requirement (i.e., at any
node) would meet the requirement.

AG: If we had more information that would be useful to the
user in an adaptive interface, what would the interface look
like? Is there a path to migrate to both the formats and the DOM?

IJ: Connection between navigation and activation - enabled
elements are also those with explicit event handlers. You
need to be able to get to actions, know about them, and activate
them. In UAAG 1.0, we struck a compromise: you only have to 
stop at nodes with explicit handlers. We don't expect UAs
to interpret scripts. We never talked about what was explicit
in markup but not on current node.

AG: There are some navigations you would miss if you only had
the inclusive solution. If the handler is making decisions based
on subnodes, you would never cover all those cases in the
navigation sequence.

IJ: I woke up this morning thinking of a two-step request: "Is
there someone listening? If yes, is it this know?" It makes
complete sense to me to factor code out and put a generic handler
at the top of the tree.

CMN: Right, you could also ask other things about behavior
(e.g., name of behavior, description, etc.). You might also
ask "Is this a generic function or does it only apply at
this node?" That information will often be available in the
description. Machine-readable information that a behavior is
bubbling seems like a low priority to me.

JG: What we're asking for in UAAG 1.0 is not what we want.  What
we want is what CMN said: If you're at a node, to be able to ask
what you can do and what will change if you do it. 

CMN: Common with rollovers: you roll over an image, figure
out which image you rolled over and replace the image. 

JG: That's easy. ATs can find this. But some events are less
universal.

AG: Whether you take the inclusive (any observer) or exclusive
(this node only) query, there are associated definitions of
navigation stops. For the exclusive query, there are more
navigation stops. For the inclusive query, there are fewer
navigation stops (only where boolean function returns true).
In the case of Jim Ley's example where there's a handler
on the BODY and there's a different behavior for each node
where it's fired, neither would give you a navigation mode
where you can walk to all available behaviors. There's also
a difference: there are some cases where there are higher
and lower level bindings to the same event (where you would
get more navigation stops for the exclusive query than for
the inclusive query). So there is a difference in coverage
between available behaviors, but this is still repair
territory. Not clear whether the difference is important.

AG: We need to talk to DOM people about whether there's a better
way to cover everything, or whether we can cut corners (and that
the cuts are not significant).

AG: The UA can fire an event at any node; and discover what
the nodes are just by reading the DOM. 

JG: Do we want more than what we have asked for currently in
UAAG 1.0? Is knowing more more useful?

AG: I consider that what the DOM WG is offering is less than
what we asked for. We should first explain why there is a
difference to the user. Need to ask them if there's a more
logical solution from their perspective that would provide
equivalent functionality in the current (unfortunate)
circumstances?

[...]

Next action: Next UAWG teleconf on events (17 Jan 2002).

-- 
Ian Jacobs (ij@w3.org)  
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Sunday, 13 January 2002 23:05:30 UTC