Re: Next events meeting: 17 Jan 2002 @ 4pm ET

At 12:40 PM 2002-01-04 , Ian B. Jacobs wrote:
>Hello,
>
>Thank you to all who attended the 20 Dec 2001 UAWG teleconf [1]
>on events, the DOM, and UA requirements. I found it very helpful.
>The next meeting to resolve open issues will be 17 Jan 2002 @ 4pm ET
>(telephone: +1-617-252-1038) for up to 90 minutes.
>
>At the 20 December meeting, we reviewed a summary [2] of what
>seemed to be the open issues. Here's the latest summary of where
>I think we are (and what we have to address on 20 Dec). 
>
>If I've made technical errors below, please send corrections.
>Also, please indicate whether there are other issues that I
>have omitted.
>
>Thank you,
>
> - Ian
>
>1) What's the best way to ensure that assistive technologies
>   can identify and trigger event handlers?
>
>Agreement: A boolean function will suffice; we don't need the list
>           of event handlers.
>
>Agreement: We do not need to fire handlers one at a time; it suffices
>           to be able to fire all handlers for a given event type.
>
>Open: Should there be one or two boolean functions for querying
>      a node N:
>  
>  a) Does N itself have a handler for event type E?
>
>  b) Is there *any* observer with a handler for event type E
>     that will be called if E occurs at N?
>
>     Agreement: In (b), because an observer may stop the capture
>     or bubbling processing phases, node N's handlers may never
>     be invoked if E occurs at N. We may know some behavior 
>     in advance from markup (cf. XML events draft [3], 'propagate'
>     attribute). 
>
>  Ray Whitmer has argued that the granularity of the query and
>  the granularity of the dispatch should be the same. If version
>  (a) of the query is chosen, then the query granularity will be
>  one node only, but a dispatch will cause processing by other
>  nodes as well. Thus (if I understand it), Ray prefers version
>  (b) and asked us to provide a use case for version (a): when
>  would an AT need to know that there's a handler on a given
>  node N, even if that node's handlers might not be triggered
>  (if an observer stops the bubble or capture process).
>
>Todo: The WAI groups need to provide a use case of when it's useful 
>  to know that an event handler was declared on the current node 
>  and not an ancestor.
>
>2) What's the best place to describe the semantics of
>   author-specified behaviors?
>
>We have not progressed much on this issue. However, there is
>some sense that this is more of a format issue than a DOM issue.
>
>Ray has stated that it doesn't make sense to be able to
>specify descriptions on a per-handler basis if you can't
>activate handlers individually. 
>
>Question: Would it be useful for the DOM to provide all
>descriptions of all handlers for a given event type? Or
>should we specify instead (one or more) descriptions for an 
>event type (rather than handler)?
>
>Please indicate what other questions WAI or the DOM WG or the
>HTML WG should answer.

Here are some of the related questions that appear to bear on the support for
events in future versions of the DOM and XML-based languages (a.k.a. dialects,
modules, ...) and accessibility consequences of those features:

Q1.x Given the capabilities/constraints of current formats, what
information is
available which would be useful to users in making an informed decision as to
activating or not activating a behavior which the author has set to be
triggered by a device-specific event?  An adaptive rebinding is required
either
when the UI adaptation of the user does not generate that event or does not
allow the un-confirmed automatic activation of the event handler for some
reason.  How would the available information be processed in a representative
adaptive interface binding (or bindings).  Some of this is guesswork or
"repair
text."  What are the options there, and the tradeoffs?

Q2.y What would it take in the operational and programming model for
event-driven behavior for 'semantic' events to be the natural medium of
exchange?  What information (analogous to the above) would be available to the
user in support of their control of web content behavior under these "If I ran
the zoo" conditions?  There are two goals, here: a) giving effective access to
behavior under varying "delivery context" situations a.k.a. interface
bindings;
and b) constructing the technology so that authors would naturally use the
indicated model well, and populate the formats with literate content, and not
simply work around the format provisions that attempt to support UI binding
latitude.

Al

> 
>[1]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0135>http://lists
.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0135
>[2]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0132>http://lists
.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0132
>[3] <http://www.w3.org/TR/xml-events/>http://www.w3.org/TR/xml-events/
>-- 
>Ian Jacobs (ij@w3.org)  
<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
>Tel:                     +1 718 260-9447
>

Received on Saturday, 5 January 2002 14:28:47 UTC