- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sun, 13 Jan 2002 23:05:17 -0500
- To: w3c-wai-ua@w3.org
[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