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

As before, I disagree with your personal opinion on these issues, and 
only by producing the use cases can we work through them, evaluate them, 
and gain consensus.  I suspect that some people will want a higher 
quality of information about the handlers than you are expecting and 
allowing for in your suggestions.  What you are proposing here is to not 
supply an accurate description of the handlers as they are available in 
the hierarchy, which are not semantic and do not follow your rules just 
because you wish they were semantic.

I do not believe what you have described here lays a good foundation for 
either proper use of non-semantic events or for semantic events when 
someone finally realizes that that is what we need them and they are not 
so difficult.  I strongly oppose any new feature which anticipates 
encouraging people to rewrite their current pages without fixing them 
and making them properly semantic.  That includes adding descriptions to 
non-semantic events.  It is trivial to add semantic descriptions (no new 
DOM code required, just look for a new attribute on the node which can 
easily be accessed through DOM) but it should only be done with semantic 
events to accomplish the use cases I have seen thus far.  Writing 
technical specifications into use cases does not help.  Saying "we need 
to enumerate event handlers" is a horrible example of a use case because 
it ignores the actual needs, and my answer is simply, no, you do not 
need to enumerate handlers.  You are saying we need handlers to be 
user-selectable.  But they are not.  You need to design them that way 
and we could have had them that way by now...  It is quite possible that 
a first stage would be practical with NO changes to a DOM level 2 
browser.  You just have to make your document handle new event types 
with semantic descriptions that page writers are encouraged to fire from 
non-semantic handlers to accomplish the real work.   The DOM model 
already permits that.

If you make a new event type called "SemanticAction" with an extra 
string semantic identifier property, and another new event called 
"SemanticEnumeration" with a way to accrue identifiers through some 
property of the event, then the same handler that decides conditionally 
whether it will handle an event based upon which node it originated on 
can let any node that asks (by firing the enumeration event) that it 
would perform a semantic action if it received the event generated from 
that particular node.  The availability can now even be stateful.  Now, 
when you ask people to rewrite their web pages, you have them supply and 
enumerate actions that might be semantically useful to someone who does 
not have the device in question into those events, which can be 
described well because they are semantic, not tied to a device.  They 
keep all the device-specific stuff in the non-semantic events, and then 
fire the semantic ones when it gets to the point that it would be useful 
as a user-selectable event.  It is a model that works, because it was 
actually designed.  That doesn't mean it takes a long time to roll it 
out because the event support is already there.

That seems to me to be  the proper way to do it.  And you don't 
hard-wire yourself to an unrealistic model that assumes that handlers 
are declared on the nodes for which they are performing actions.  This 
probably covers 80%, but obviously, there is more that can be done here 
if you want the invoker of the SemanticEnumeration and SemanticAction to 
know how to supply additional arguments such as simple values or 
association with a second node (for things that in a UI would be a 
drag-and-drop type action), etc.  It is hard to see in any of this where 
we need new DOM features.  Describing these semantic events would be a 
proper thing.

Ray Whitmer
rayw@netscape.com

Jon Gunderson wrote:

>> 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.
>
>
> JRG:  I think we only want current node. We have no real use for 
> bubbling information at this point.
>
>> 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)?
>
>
> JRG: This seems to be more a markup issue.  The markup language should 
> provide a means to associate the purpose/function of a script to a 
> particular event handler.  One possible solution is some thing similar 
> to the label element for form controls.  This would be considered 
> conditional content, form a UAAG point of view, and could be made 
> available to the user through the DOM or the User Interface.
>
>
>
>> Please indicate what other questions WAI or the DOM WG or the
>> HTML WG should answer.
>>
>> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0135
>> [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0132
>> [3] http://www.w3.org/TR/xml-events/
>> -- 
>> Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
>> Tel:                     +1 718 260-9447
>
>
> Jon Gunderson, Ph.D., ATP
> Coordinator of Assistive Communication and Information Technology
> Division of Rehabilitation - Education Services
> MC-574
> College of Applied Life Studies
> University of Illinois at Urbana/Champaign
> 1207 S. Oak Street, Champaign, IL  61820
>
> Voice: (217) 244-5870
> Fax: (217) 333-0248
>
> E-mail: jongund@uiuc.edu
>
> WWW: http://www.staff.uiuc.edu/~jongund
> WWW: http://www.w3.org/wai/ua
>
>

Received on Friday, 4 January 2002 16:57:52 UTC