00:01:49 RRSAgent has joined #webapps 00:01:49 logging to http://www.w3.org/2013/10/02-webapps-irc 00:02:44 I am here 00:02:45 . 00:03:00 I'm here. 00:03:29 rrsagent, this meeting spans midnight 00:04:40 I think this is the current draft: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html 00:05:39 Present+ Travis 00:05:48 Present+ garykac 00:05:57 Let's get started! 00:06:05 Shall we start going through the spec? 00:06:24 garykac: All issues should be reflected in the doc. 00:07:06 Skipping over Issue 2 (spec mouse event order) 00:07:15 Search the doc for "issue " :-) 00:07:54 kochi_home has joined #webapps 00:08:02 Issue 3... 00:08:21 should right/middle button generate dblclick 00:08:22 No consistency between browsers on the issue currently. The bug is to request the old Presto (Opera) behavior. 00:08:45 It sounds like the recommended approach is the least compat-risky. 00:09:41 I like firing click event for any buttons. 00:10:34 Present+ kochi_home 00:11:52 It will be hard to be consistent across browsers... 00:12:04 Not firing the events seems like the safest approach... 00:13:24 The effect of making this change would be to say "there is a 'primary' mouse button, and it's action is to fire click events--any other button would not do that". 00:13:35 This is a fairly straightforward story to tell. 00:14:29 If there is no click event, web app develpers need to handle both mousedown and mouseup. 00:14:34 The alternative is that *all* buttons need to generate these events. And if we have a device with 15 buttons, they would all need to generate these events. 00:14:35 The notion of a "primary" mouse button is not new to the spec, so could be easily leveraged here. 00:15:39 If there is no dblclick event, they need to hande the events while a specific time but they don't know the good term for dblclick. 00:16:23 Clickcount is supposed to do that. 00:16:29 I propose that we pick a direction and commit it to the spec (even if it's wrong) 00:16:31 (but it may not be consistent) 00:16:35 I agree with "*all* buttons need to generate these events". 00:17:15 masayuki: See the argument in the bug: The problem with Blink/WebKit's approach is that sites do something on click which doesn't make sense to do if the user clicks the link with the middle mouse button which should open the link in a new tab. Both actions happen which is not what the user expects. 00:18:07 Browsers are playing tricks to mitigate the problem. 00:18:25 I'm generally supportive of moving the click action to the primary button only. 00:18:46 Mouse down/up's are still fully functional. 00:18:47 Travis: I think that it's site specific problem. Are there too many such sites? 00:19:29 Well, it's the user-interaction problem, not a site problem. 00:19:46 I (the user) want to middle-click to open in a new tab. 00:21:19 I think that middle click event should be available on web apps but if they handle it, they should call preventDefault(). And then, browsers shouldn't open new tab. 00:22:17 OK, let's take this discussion to the bug--masayuki, I think you make a good argument, we should continue this conversation there for full exposure. 00:22:23 Let's move along. 00:22:28 Issue 4 00:25:05 garykac: ...was looking at a newer version... back on track now. 00:26:38 I'm not sure what locale is trying to accomplish; is it keyboard layout? Is it language? 00:27:07 It's pretty ambiguous [sometimes], e.g., US-international. 00:27:19 I think it's OS's keyboard layout, not physical keyboard layout. 00:27:22 How might EN-US international layout be expressed with BCP 47? 00:27:35 The issue with locale is that the CompositionEvent uses is as well. If we remove it from the KeyboardEvent, we'll still have a locale_ in the IME events. 00:29:10 I created an experimental patch for Gecko, but I cannot implement consistency behavior across platforms... 00:30:00 garykac: I think that we should drop it from both KeyboardEvent and CompositionEvent in D3E. 00:31:06 I believe that we need better idea for computing the value. 00:31:41 I agree 00:32:03 The best it could do is report the OS layout - but it will usually match the physical keyboard 00:32:21 masayuki: agreed 00:32:33 I'm concerned that the IME events may need it though 00:33:08 In Win8 Language and Keyboard layout are fairly independent. 00:33:15 So, it sounds like we should move locale into UI Events 00:33:25 garykac: what's case do you concerned with IME? 00:33:53 I recall hearing that locale was used to help identify which IME language 00:34:15 I don't have an example of where it would be necessary, however. 00:34:37 I do think being able to detect the lanaguage is key for IME scenarios. Locale as the keyboard layout may not have been accurate, but was loosely sufficient. 00:35:03 IIRC, it was useful for distinguishing between Japanese, Chinese, et al. 00:35:10 I would certainly want the IME API spec to pick up something to fill the gap, if we chose to remove locale from D3E. 00:35:26 Sure, I'll add it to my TODO. 00:37:00 Let's try to make progress on the bug. I think if we can coordinate with IME API that might be great. 00:37:08 No action on issue 4 yet. 00:37:37 issue 5 00:38:38 Gecko doesn't dispatch any key events during composition, but we *can* change the behavior. (need a lot of time, though). 00:38:48 Issue 5 is apparently resolved 00:40:37 Related to issue 5: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23258 00:42:17 Chatted with folks who did the IME API work in IE11--they do all their IME adjustments in the compositionupdate event, and wanted the DOM to be current when the event was fired. 00:42:26 (It is current today.) 00:44:02 There is no commentary on bug 23258, so I don't know how anyone else thinks about this. 00:44:23 I need to review the spec to make sure it's consistent with what we decided during the last call. 00:44:26 Gary didn't notice some inconsistencies in the spec with the written order. 00:44:34 s/didn't/did 00:44:53 Then I'll compare that with the new bug Travis links above and make sure there are no new issues. 00:45:01 Any other feedback on issue 6? 00:45:03 Are there useful case for catching the composition updating before actually DOM is changed? 00:46:09 If it's necessary for some developers, making compositionupdate and compositionupdated events may be good solution. 00:46:56 masayuki: Perhaps trying to cancel before the DOM is updated? 00:47:29 masayuki: can beforeinput be used for catching event before DOM is updated? 00:48:48 kochi_home: If it's true, isn't input event enough for catching DOM change? 00:49:47 maybe, so compositionupdate event is for getting the composition text itself, not the whole value in the field? 00:50:08 beforeinput and input serve that purpose for most developers. 00:50:18 If the compositionupdate event _included_ all the relevant IME info, then I think this is a moot point. 00:50:29 kochi_home: yes 00:51:13 the composition events don't need to wrap the DOM update - it would be nice to place it consistently before (or after - whatever we agreed on last time ^_^) 00:51:38 The web dev would just have to know that they shouldn't read the DOM during composition (if it happens before)--they'll always be getting stale input. 00:52:14 but beforeinput and input should handle the "i need to know before the update" and "i need to know after the update" cases 00:53:03 I think that we have all the right notifications for input changes before and after. 00:53:37 Moving to issue 7 00:54:23 For issue 7, just file a bug if there are any other examples that should be included 00:57:20 Might be nice to callout the scenarios enabled by UIEvent's 'code' property, lest there be any compaining at CR time. 00:58:07 Let's stop here for today. 00:58:15 Topic: TPAC planning 00:58:41 I've been waffling... 00:58:51 I haven't made arrangements yet, but I'm still considering. 00:58:51 I will be attending all week. 00:58:54 i'll be there 00:59:06 If I go, I'd be stopping in Tokyo afterwards. 00:59:16 garykac: nice! 00:59:23 Do we want to plan on achieving any specific milestone for the event? 00:59:40 E.g., getting a new WD published? 00:59:46 Or event pushing for CR? 00:59:52 We should certainly try for that. 01:00:44 garykac: New issue count has dropped... 01:00:52 ... and we're making pretty good progress. 01:01:22 ... many of the issues are "fluffy" (can be resolved easily). 01:01:45 We're roughly 5 weeks from TPAC 01:02:13 Historically there's been a publishing blackout for 2-3 weeks prior to the event. 01:02:31 That leaves us with about 2 weeks to prepare for re-publishing. 01:05:52 I propose we meet again next week to keep our momentum going... 01:06:14 Can folks make another telco/IRC chat on the 8th? 01:06:35 Masayuki: Do you ever head into Tokyo? It would be nice to meet in person after TPAC if possible. I might be in Tokyo that Friday (15 Nov), but I'm still working out arrangements. 01:08:04 garykac: perhaps, I can go Tokyo. 01:08:23 masayuki: nice! 01:08:48 Let's meet again next week then. 01:09:08 But, 17 Nov, I have a plan in Osaka/Kyoto. So, I need to be back at least 16 Nov. 01:09:10 in that case, I'll be at TPAC Mon-Wed, go back to Tokyo on Thu, then meet Gary and Masayuki on Fri. 01:09:34 (tentative plan) 01:10:46 OK. I'll keep you posted with my travel arrangements. Hopefully, it will all work out. 01:10:56 garykac: Feel free to kick off specific mails to move issues along on the public list. Might help move things along faster. 01:11:05 thank you everyone. 01:11:07 Thanks everyon! 01:11:13 thanks! 01:11:16 Thanks! 01:11:37 rrsagent, please make the minutes 01:11:37 I have made the request to generate http://www.w3.org/2013/10/02-webapps-minutes.html Travis 01:11:51 rrsagent, set logs public 01:15:21 Wiki is now updated. 01:15:26 bye rrsagent 01:15:30 bye zakim 01:15:55 Zakim: bye! 01:16:02 Zakim: see ya 01:16:12 zakim, you can leave now 01:16:12 I don't understand 'you can leave now', Travis 01:16:16 zakim, bye 01:16:16 Zakim has left #webapps 01:16:24 rrsagent, bye 01:16:24 I see no action items