23:59:57 RRSAgent has joined #webapps 23:59:58 logging to http://www.w3.org/2014/04/15-webapps-irc 00:00:07 RRSAgent: this meeting spans midnight 00:00:26 zakim, this will be dom3 00:00:26 ok, Travis; I see RWC_WAPI(D3E)8:00PM scheduled to start now 00:00:38 Will start the meeting soon, right? You wrote wrong time of Tokyo due to summer time. 00:00:59 I realized it now :-) 00:01:13 Ooops. 00:01:53 kochi_mtv has joined #webapps 00:01:58 RWC_WAPI(D3E)8:00PM has now started 00:02:05 +[Microsoft] 00:02:15 Present+ Travis_Leithead 00:02:23 Zakim: Microsoft is Travis 00:02:49 + +1.425.893.aaaa 00:02:51 Zakim: [Microsoft] is Travis 00:03:26 Present+ Gary 00:03:29 garykac has joined #webapps 00:03:53 Zakim: 1.425.89 is garykac 00:04:04 https://docs.google.com/document/d/1mRTqY-2la5keSHhJUtEvSG3brMe_W3KRlkLWFVbV9yM/edit?pli=1 00:04:15 + +1.650.214.aabb 00:04:20 scribe: travil 00:04:32 masayuki_ has joined #webapps 00:04:42 Present+ kochi 00:05:06 Zakim: 1.650.214 is kochi 00:05:33 kochi: I was at the WebApps f2f and presented the IME api 00:05:48 ... nothing much was discussed about DOM3, outside of what is in the minutes. 00:06:05 garykac: I saw that, and wondered if there was any extra conversation. 00:06:16 kochi: Gary, did you dial into the f2f meeing 00:06:26 garykac: No, didn't know when to do so. 00:06:40 scribeNick: Travis 00:07:06 Topic: DOM3 Events at the F2F 00:07:52 garykac: Looking at the minutes... 00:08:00 Link to minutes: http://www.w3.org/2014/04/10-webapps-minutes.html 00:09:40 What is PointerEvent's dependency on UIEvents? 00:09:42 garykac: notes say there is a dependency on UIEvents spec??? 00:10:10 If it's |buttons|, I believe we have all that in D3E. 00:10:24 Travis: I think this was for the 'buttons' change to support the value of -1 (where it was previously defined as an unsigned long 00:10:45 ... I updated the spec for that. 00:10:53 We should confirm that and let them know they depend on D3E now. 00:13:00 garykac: also note about plan to split the spec... 00:13:04 From the f2f, there was agreement to break out the |code| and |key| tables if that can speed up the spec. 00:13:40 Travis: This was the WG acknowledging that anything to speed up the process of finishing the spec 00:14:00 All three docs (D3E, co]de-values and key-values) will live in the same Hg repository for now. 00:14:24 ... It was suggested that a registry or wiki would do, but we think another rec-track doc is sufficient and only adds minor overhead. 00:14:31 Topic: Recent document updates. 00:14:42 The doc above has the latest status of the bugs 00:15:14 I think that it's better we can change the code/key table even if we found some new bugs in the table *after* D3E finished. 00:15:44 garykac: masayuki_: I agreee 00:15:45 Exactly, that's why we want to do that - it'll make updating the tables a lot easier 00:16:05 garykac: Now, noting that lots of old bugs in the doc are fixed! 00:16:36 At the bottom of the doc are the closed bugs. Please review them (later!) and make sure there's nothing overlooked when they were fixed. 00:17:10 Question: In 5.2.7.5 "Key Events During Composition". 00:17:31 Yeah, I'll review the closed bugs and I'll comment some bugs which ask some questions from garykac or Travis. 00:17:43 I'm wondering if we should change "SHOULD be suppressed" to "MAY be suppressed"? 00:18:37 I think so > "SHOULD" vs. "MAY". 00:19:17 "SHOULD" is good for "keypress". 00:19:39 Well, keypress is deprecated ^_^ 00:20:17 In the doc, let's start at the bottom of the list (since those are the newer ones) 00:20:37 Bug 25359 - Use [Unforgeable] and [NewObject] annotations in D3E 00:21:03 I *think* this is straightforward, but I wonder if there are other new annotations that we should be using. 00:21:03 Yeah, but it's clearer for authors if we define keypress event's reference behavior. 00:21:19 Travis: are you familiar with these annotations 00:22:43 Yes. 00:22:45 I can easily fix isTrusted and createEvent, but I want to make sure we update any other cases as well. 00:23:18 Travis suggests updating this bug to note that we need to compare D3E with D4 and make sure the IDL matches 00:24:22 (I just updated the bug to note that we need to compare with D4) 00:24:41 Bug 25358 - "Context info: UIEvent.view" sometimes only has defaultView 00:25:29 This requires that we double check and verify the correct values - I don't know offhand. 00:25:35 sicking has joined #webapps 00:26:25 Should all of these allow 'null'? 00:27:47 The view should always be a Window (abstractView) if the event is Trusted. 00:28:18 ... Since these can be trusted/untrusted, the view attribute can always be null. 00:29:17 I've updated the bug to note that we'll be changing it to allow null. 00:29:50 25357 - Target for event type is not complete 00:33:20 Bug 25210 - Targets for abort event is correct? 00:33:48 For 25357 - I updated the bug to note that we need to update the tables to be consistent. 00:35:09 For 25210, we need to make it consistent with what HTML5 says. 00:37:39 Bug 24797 - We've fixed this, so this is no longer a D3E issue. I'll be resolving (again) with a note that the Window vs. WindowProxy issue should be addressed in a more appropriate doc. 00:38:48 big 24044 - How do browsers decide combining character from non-combining character at computing .key value of dead key? 00:38:55 s/big/Bug/ 00:39:16 I need to think more about this, so we should move on to the next one. 00:39:34 Bug 23913 - beforeinput should be fired only when the DOM change is caused by direct input by keypress or composition 00:39:46 I think that using DeadKey is smart since authors can get input value with input/beforeinput/compositionupdate events. 00:40:55 Consensus (as far as I can tell) is that we shouldn't fire beforeinput/input for execCommand 00:41:36 We don't currently discuss execCommand anywhere in the D3E - I suppose that I can just add a note in the InputEvent section about this. 00:41:49 About bug 23913, I think that if browser thinks "dangerous" to dispatch beforeinput at some cases, browser shouldn't dispatch beforeinput. I.e., before should be defined with "MAY". 00:42:32 Then, even with execCommand, browsers might be able to dispatch beforeinput safely. 00:43:02 WE should define the dangerous cases if we can. Most of the time it is clearly not dangerous, so saying MAY doesn't seem right. 00:43:12 What other dangerous situations are there other than execCommand?> 00:44:07 I'm not familiar with "dangerous" cases... Olli or Boris of Mozilla might know about it... 00:44:09 Script modifications to the value of an input element wouldn't trigger beforeinput, correct? 00:44:41 I guess the idea that execCommand is a proxy for a user input, then that makes it dangerous. 00:44:57 Anyway, I need to implement beforeinput experimentaly, first... 00:45:01 Real automation systems like WebDriver would still cause the event to fire though. 00:45:24 We just want IME systems to also fire it. 00:45:26 I'm happy have a "when not to fire beforeinput/input" section that listing the situations when it's not appropriate. We could start with execCommand and add to it. 00:45:47 I think that sounds good to address this concern. 00:45:51 I would hope that automation systems would fire these events (otherwise testing will be hard). 00:46:07 I strongly believe that "input" should be fired always since current browsers implement so. 00:46:39 I don't think that beforeinput and input should always be fired as a pair. 00:48:10 beforeinput and input are supposed to be fired as a pair - the DOM has already been updated by the time the input event it sent. beforeinput is the last change to look at the DOM before the update. 00:49:55 Anyway, it might be better to keep this discussion in bug 23913. 00:51:07 Yes, but the discussion died down and no one responded (>sniff<) to my call for comments. 00:51:49 But keeping the conversation in the bug sgtm 00:52:04 Yep, I'm sorry about that... 00:53:16 chaals has joined #webapps 00:57:58 Is there anything else to discuss before we stop? 00:58:28 FYI: I'm implementing KeyboardEvent.code now. 00:58:53 FYI #2: I implemented KeyboardEvent.isComposing and InputEvent.isComposing. 00:59:00 BTW, masayuki, thank you for filing all those great bugs 00:59:04 Of course, on Firefox. 00:59:45 garykac: you're welcome. 01:01:15 OK. I think that we're done for today. 01:01:22 I'm hoping to close out more bugs for next time, 01:02:05 Should we meet next week? Same time? 01:02:30 RRSAgent: please make the minutes 01:02:30 I have made the request to generate http://www.w3.org/2014/04/15-webapps-minutes.html Travis 01:02:40 Travis says that next week sounds good.' 01:02:43 - +1.650.214.aabb 01:02:46 -[Microsoft] 01:02:57 - +1.425.893.aaaa 01:02:58 RWC_WAPI(D3E)8:00PM has ended 01:02:58 Attendees were [Microsoft], +1.425.893.aaaa, +1.650.214.aabb 01:03:00 RRSAgent: make minutes public 01:03:00 I'm logging. I don't understand 'make minutes public', Travis. Try /msg RRSAgent help 01:03:10 RRSAgent: make logs public 01:03:13 I'm ok to meet next week. 02:38:42 karl has joined #webapps 05:05:08 lgombos has joined #webapps 05:25:06 lgombos_ has joined #webapps 05:26:36 lgombos__ has joined #webapps 06:26:52 schuki has joined #webapps 07:32:10 Zakim has left #webapps 08:08:44 sicking has joined #webapps 08:09:22 skddc has joined #webapps 08:20:20 richt has joined #webapps 09:38:39 gavin_ has joined #webapps 09:44:05 dom has joined #webapps 10:20:49 abarsto has joined #webapps 11:03:19 smaug has joined #webapps 11:15:17 Lachy has joined #webapps 11:20:51 RRSAgent, make minutes 11:20:51 I have made the request to generate http://www.w3.org/2014/04/15-webapps-minutes.html ArtB 11:21:14 Meeting: DOM 3 Events Call 11:21:27 Chair: Travis 11:21:35 RRSAgent, make minutes 11:21:35 I have made the request to generate http://www.w3.org/2014/04/15-webapps-minutes.html ArtB 11:22:28 rrsagent, bye 11:22:28 I see no action items