- From: jongund <jongund@ux1.cso.uiuc.edu>
- Date: Thu, 17 Jan 2002 14:39:20 -0600
- To: w3c-wai-ua@w3.org
Present: JG: Jon Gunderson (Chair/Scribe) DP: David Poehlman DA: Denis Anson AG: Al Gilman SP: Steven Pemberton PH: Philippe Le Hegaret LB: Lee Bateman RW: Ray Whitmer HB: Harvey Bingham CMN: Charles McCathieNevile RS: Richard Schwerdtfeger [13:04:38] *** chaalsNCE has joined #ua [13:05:06] <JRG> CMN: Charles McCathieNeville [13:05:07] *** halindrom has joined #ua [13:05:41] *** Steven has joined #UA [13:07:11] <JRG> DP: David Poehlman [13:07:52] <JRG> HB: Harvey Bingham [13:08:15] <JRG> First Item is the proposal for the boolean function node [13:08:51] *** Al has joined #ua [13:09:02] <JRG> PH: 2 issues WAI and DOM only [13:09:18] <JRG> We don't to expose the list of listerner [13:09:27] <JRG> We want to know about the mouse event [13:09:45] <JRG> Do we include capture and bubble phase [13:10:10] <JRG> Do we include any element in the event path [13:10:27] <JRG> If you have a listner in any of the event path [13:10:42] <chaalsNCE> q += chaals [13:10:45] <Al> hand up [13:10:48] <JRG> Some people still want to know on specific nodes [13:11:27] <JRG> CMN: We know if there is an event on the current node, it is part of nav for UAAG [13:13:03] <JRG> AG: We have to realize there is an expanded use case [13:13:05] <chaalsNCE> Need to know if there is an eevent listener for an element, but don't need to know whether the event is on that element explicitly or listens in the bubble/cpture phase [13:13:47] <JRG> The user only have effective access to nodes that are part of the nav stops [13:14:12] <JRG> Which elements will respond to an event [13:15:19] <JRG> SP: So you want to if there is an specific event is on this node [13:15:51] <Steven> Rather: You want to know if anything is going to repond to an event on this node. [13:20:13] <JRG> PR: You can construct the information on a specific information from the the path test [13:20:28] <chaalsNCE> q += chaals [13:20:41] <Al> PLH: That computation does not tell you when an event is re-bound further down the tree. [13:23:08] *** TimLa has joined #ua [13:23:11] <JRG> AG: Most of the time an event that is lower will not be captured by higher [13:23:15] <TimLa> Timla's here [13:23:20] <JRG> PH: The use case? [13:23:56] <JRG> AG: In the case where event is bound at the low and high level. You can not compute the difference. [13:24:11] <JRG> PH: [13:25:00] <chaalsNCE> did that improve sound? [13:25:05] <JRG> The response to your problem is [13:25:06] <JRG> yesy [13:25:08] <JRG> yes [13:27:40] <JRG> AG: What did ray agree to [13:28:23] <JRG> RW: It is advantageous to have both fuctions to add in developing a nav path [13:28:47] *** Steven changes topic to 'WAI UAWG teleconf backchannel' [13:28:59] <JRG> All the user needs to navigation along and a parent an a child declared the same event handlers [13:29:30] <JRG> This is justification function for two functions or a one function with a state switch [13:29:41] <JRG> PR: i am OK with this [13:29:49] <JRG> It is user requirement [13:30:23] <JRG> SP: I am neutral of DOM functions. If there is a use case it should be included. [13:31:28] <JRG> CONSENSUS [13:31:57] <JRG> Boolean function for both the path and explicit event handlers [13:32:28] <JRG> PR: In HTML when you have an onEvent is it defined.. [13:32:41] <JRG> SP: Everybody listens to click [13:33:10] <JRG> PR: For an activate event trigger onClick? [13:33:20] <JRG> AG: I don't think is clear [13:33:37] <JRG> SP: What I am proposing to just have activate in XHTML 2.0 [13:33:47] <JRG> CMN: clapping [13:33:59] <JRG> RW: You may find opposition [13:34:33] <JRG> AG: We have completed item 1 [13:34:44] <JRG> We can go off line and get details [13:34:53] *** rayw has joined #ua [13:36:03] <JRG> Action DOM to update draft, will cone back to UAAG [13:36:58] <JRG> Describing Events [13:37:13] <JRG> RW: Simpliest type of semantic events [13:38:04] <JRG> It defines an action event, that is named. It separates out an action that is not tied to a device [13:38:27] <JRG> the other action you can do is what actions are available at this node. [13:38:43] <JRG> This could be used to build a menu of actions for a node. [13:38:54] <chaalsNCE> q += chaals [13:39:03] <JRG> Where ever you need to separate from the hard ware use the names to do a mapping [13:39:20] <JRG> The mechanisms are already in place [13:39:38] <JRG> PR: Question for ray [13:39:47] <JRG> I understand your action event [13:40:20] <JRG> RW: If you are on a node you fire this event and the event responds with a list of events [13:40:36] <JRG> PR: When you attach a mouse event [13:41:04] <JRG> RW: You only do a mouse things with a mouse or translate than to a semantic event [13:41:21] <JRG> The actions are device independent [13:41:29] <JRG> PH: A new event system [13:42:12] <JRG> RW: No you don't need to, it sits on top of the exists DOM system [13:42:53] <JRG> AG: This appears to me DHTML designers, this is pure carrot, no stick [13:43:02] <JRG> One use case this does not support [13:43:43] <JRG> In the user agent guidelines there is configuration, [13:43:54] <JRG> RS: Rich S joined [13:44:10] * Steven has an answer to the mapping to click event question at a suitable point [13:44:39] <JRG> AG: What do with nav and window methods [13:44:56] <JRG> In the ideal world you would now more about the actors than the names in the menu [13:45:29] <JRG> If you could classify roll overs that is was just changing style, that would be useful to ignore these events [13:46:12] <JRG> Al reasies the issue of style versus content changing events, can these be coded in the descirption. [13:46:28] <JRG> There may also be a severity of the changes to the document [13:46:58] <JRG> RW: Is this additional information, useful for what you put on the menu or what you do after you get it [13:47:19] <JRG> AG: The user would be able configure what is on the menu [13:47:38] <JRG> If you can have an undo for the event, you need to know before the event [13:48:03] <JRG> RW: This prposal is not a finished this. We could report additional informtion. [13:48:22] <JRG> Part of the model might include information on what the events does. [13:48:32] <JRG> TL: Tim Lacy joins [13:48:57] <JRG> AG: I have one headline with SP [13:49:39] <JRG> CMN: Question, where are we going? [13:49:57] <JRG> Give me the event name, like onMouse... [13:50:07] <JRG> Is that what this would do? [13:50:26] <JRG> RW: There would be semantic event, so these would not be in the list [13:50:54] <JRG> CMN: What about existing cases with documents with onMouse over. [13:51:40] <JRG> CMN: the idea of an existing page withe existing events, what it would tell you know is the onMouse stuff [13:52:03] <JRG> In the future we could call that roll over [13:52:23] <JRG> In the backward case, you get the onMouse information [13:52:46] <JRG> There is a limited set of events, mouse over usually do this [13:53:01] <JRG> Legacy will be based on user experience [13:53:20] <JRG> AG: If you don't find what is on the page, you try the legacy [13:54:00] <JRG> CMN: What you want to do is attach a description, you can query an event for a description. How do you attach this to the event. [13:54:12] <JRG> RW: My proposal covered that. [13:54:55] <JRG> CMN: No no no, first you do semantic event, and connect a description to the semantic event [13:55:30] <JRG> AG: It would seems to me for the handlers to publish this information throught the DOM and not the events module [13:55:39] <JRG> Have you considered this option? [13:56:40] <JRG> RW: From my prespective, the current problems. Which nodes above these other nodes services, sending an event out that are particularly better uses the existing system unchanged/ [13:56:58] <JRG> RS: What would we do with existing Java Script [13:58:00] <JRG> CMN: Existing system will die off. Today you find out what is going on with today Java script code. It becomes clear to developers that they can call this event by an more interesting name. [13:59:19] *** halindrom has quit IRC ( ) [13:59:22] <JRG> They will continue to use onMouseOver will call highlight. The next bit is to make the leap to a specific device. Designers will want to leave a hint on the typical interaction. [13:59:48] <JRG> You can map behaviors on the acerage desktop devices [14:00:34] <JRG> People will be able to deal with existing Java Script since there is a limited scope of how people use JavaScript. [14:01:13] <JRG> AG: It gives you a local elaboration [14:01:33] <JRG> You need more naming or labeling if something has changed. [14:01:43] <JRG> RS: Is there anything that can be done now? [14:01:59] <JRG> AG: if we had nem.. names [14:02:29] <JRG> CMN: Javascript names are somewhat descriptive of the eent [14:02:39] <Steven> q+=steven [14:02:54] <JRG> CMN: We want something more. You want to provide explicit documentation. [14:03:26] <JRG> We need some new markup for describing events [14:03:44] <JRG> Designers will want to define there assumed default behavoirs [14:03:59] <JRG> AG: We may need to provide a hint of the mapping [14:04:14] <JRG> RW: Seems to be a natural extension [14:04:50] <JRG> AG: We have some important information, I don't know how new this information is to X events [14:05:17] <JRG> SP: I think it is alright for me to take this information back [14:05:27] <JRG> How do represent the handlers [14:05:39] <JRG> We will have something called description [14:06:02] <JRG> With the realization that this still requires authors to do it. [14:06:26] <JRG> AG: Does it make sense to have a DOM and XHTML events [14:06:44] <JRG> SP: Will people be at Plenary? [14:06:52] <JRG> AG: some people will be there [14:07:00] <JRG> SP: How about an hour [14:07:20] <JRG> AG: we have about 4-5 weeks. Do you want to be public? [14:07:34] <JRG> SP: Doesn't matter what list [14:07:48] <JRG> AG: This is not member confidential [14:07:57] <JRG> I will take this off line [14:08:12] <JRG> AG: leaves [14:08:46] <JRG> SP: What happens now in HTML with stuff like on click [14:08:57] <JRG> What does the browser do? [14:09:20] <JRG> Netscape 6 and IE 5 and Opera, Current browsers [14:10:28] <JRG> RW: This practical problem. I think Opera has the right one. [14:10:43] <Al> sayonara [14:10:50] <JRG> SP: Since there is not an onActivate in HTML 4.0 [14:11:10] <JRG> CMN: you can do on keyDown [14:11:27] <JRG> SP: This needs to be fixed [14:12:21] <JRG> CMN: I just wanted to clarify, that people behavior should drive the inclusion of a feature for acceesibility [14:12:36] <JRG> SP: In the HTML working groupw e are discussing NOSCRIPT Notes continue off line PR: Do we want to do this in DOM level 3 CMN: The action on WAI is to given that this proposal works, we would like to see it works. PR: I think we need to have it DOM level 3 CMN: UAAG and PF needs to consider it and get back to the DOM working group. RW: We need to have compelling nature of this thing for us to see an effect RS: How does this affect authoring CMN: Yes PR: The boolena is in DOM level 3 We need to the action list feedback from WAI ACTION JG: Take proposals to WAI CG and discuss ********** new topic ************ RS: Implementation report? JG: Iam has been doing more evaluation and we should be updating our report RS: Improving techniques document? JG: Send to list and Ian will add when he has time. He would like to publich a new working draft soon
Received on Thursday, 17 January 2002 15:39:21 UTC