00:00:43 RRSAgent has joined #webapps 00:00:44 logging to http://www.w3.org/2014/04/30-webapps-irc 00:00:48 Zakim, this is DOM3 00:00:48 ok, Travis; that matches RWC_WAPI(D3E)8:00PM 00:00:56 Present+ Travis 00:01:09 RRSAgent: this meeting spans midnight 00:01:35 scribe: Travis 00:01:40 scribeNick: Travis 00:01:55 waiting for others to join... 00:02:06 Travis: Hello. 00:02:16 Hi! Glad you could make it! 00:03:24 We've been making some progress on the bugs this past week. 00:04:29 Regarding bug 24044: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24044 00:04:52 I think the solution is to add the key value "DeadKey" correct? 00:07:21 A dead key process causes a set of composition events. So, web apps can get the inputting value of dead key sequence even if .key value is "DeadKey". 00:07:59 Right. Through the "data" value of the compositionevent objects. 00:08:24 Therefore, I think that "DeadKey" is simple solution for the issue. 00:08:35 Me too. 00:09:25 It's hard to define a mapping table for combining characters <-> non-combining character... 00:09:34 + +1.425.936.aaaa 00:09:44 I'm looking at the key events tables now, to try and find where to slot in this new value... 00:09:57 garykac has joined #webapps 00:10:02 zakim, +1.425 is garykac 00:10:02 +garykac; got it 00:10:38 Present+ garykac 00:10:51 Welcome gary! 00:11:07 Hi, gary. 00:11:07 We can start with https://www.w3.org/Bugs/Public/show_bug.cgi?id=25338 00:11:18 Clear vs. NumLock 00:11:24 -garykac 00:11:45 I think that Clear is better because NumLock implies a locking state for the key. 00:12:13 I don't think that this causes problems since the Mac has no NumLock key 00:12:48 +garykac 00:14:06 garykac: I agree, but they are same physical key at least with USB HID spec. 00:16:51 USB spec has both Keypad NumLock/Clear (53) and Keypad Clear (D8) 00:17:55 So we could go either way. 00:18:20 Looks like this on my current keyboard: http://www.bing.com/images/search?q=microsoft+sculpt+number+pad&FORM=HDRSC2#view=detail&id=F9469927A0E2504497E3C941499BD5C903520074&selectedIndex=22 00:19:05 garykac: Yeah. I confirmed that the clear key on Mac keyboard is NumLock key, not the Keypad Clear. 00:19:46 If Clear == NumLock, what codes should my keyboard report for these? 00:20:32 The Clear key on the Mac reports itself using the same code as Windows NumLock 00:20:53 We still need to keep the NumpadClear around (for the keypad that Travis just posted). 00:21:19 But if it makes life easier to have the Mac Clear key use the same |code| value as Numpad, then that's fine with me 00:23:28 I've updated the bug to note that I'll change it so Mac Clear = NumLock. I'll have to add a comment explaining why that is the case. 00:25:39 garykac: Thanks. If web apps need to distinguith the behavior, they should use .key which should return "Clear" only on Mac. 00:26:40 sgtm 00:29:06 Masayuki: I didn't get a chance to fix 23906 (accelKey), but I want to have that written up for you to review by next week. 00:29:40 garykac: no problem. 00:31:40 I just looked over bug 25477, and assigned to myself--pretty trivial update to the KeyboardEvent.init* method. 00:33:12 I backed out the KeyboardEvent.initKeyboardEvent() from Firefox 31 (Nightly). 00:33:40 I.e., we decided that we'd never support it. 00:35:10 I have no problem with that :) 00:35:28 Now looking at: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23913 00:35:49 Yeah, web apps should use event constructor on IE and Firefox... 00:36:11 For 23913 (beforeinput firing), it sounds like we need to add a note that beforeinput may not be cancelable when it is unsafe (or if the IME does not permit it). 00:36:38 sgtm 00:38:10 If so, unsafe beforeinput's preventDefault() just change defaultPrevented attribute? or not change the value? 00:39:01 mousemove's preventDefault() changes only defaultPrevented value. So, I think it's no problem, it changes only defaultPrevented value. 00:39:38 What does "unsafe" mean--I'm not sure... 00:40:06 Ah, comment 16.. 00:40:28 For example, Firefox thinks during setting .value is unsafe. 00:41:05 It would be nice to define "unsafe" situations in the spec, if possible. 00:41:43 Re: beforeinput preventDefault behaving the same as mousemove preventDefault. sgtm 00:42:13 garykac: Yeah, but I'm not sure exacely when Firefox thinks it's unsafe. And it needs to refer a lot of other specs... 00:42:26 Ugh. ^_^ 00:43:03 "unsafe" refers to dispatching a synchronous event during a pre-existing script stack, such as one changing the .value of an input? 00:43:49 Then having an example unsafe scenario to use in the spec description would be good. 00:44:14 Probably execCommand or .value would be a good example. 00:44:24 We should ask Smaug (Olli) about it... 00:46:09 masayuki: do you talk to him frequently? or should we ping him on the bug? 00:47:11 garykac: I'll email him about it and request to write comment into the bug. 00:47:24 masayuki: thanks! 00:50:58 Travis make a comment drawing parallels between beforeinput and mutation events... 00:57:56 (Gary and I discuss execCommand a bit) 00:58:02 masayuki: if beforeinput doesn't fire for modification made by scripts or execCommand, does that cover all the problem cases? 00:58:51 garykac: I guess so, but I'm not sure. 00:59:45 so user actions (including cut/paste) always result in beforeinput/input, but scripted dom modifications will not generate beforeinput. (Should 'input' not fire as well in this case?) 01:00:20 input should be fired for compatibility with current browsers. 01:00:57 Ah. good point. so 'input' sticks around in that case. 01:01:45 Does 'input' fire for script events, or only for execCommand? 01:02:10 masayuki: ^^ (question about FF) 01:02:37 When I tested, input did not fire for regular script modifications, but I didn't check execCommand. 01:03:08 I'm fine suppresses 'input' in those cases as well -- unless we need to keep it around to match current behavior. 01:03:36 IIRC, input event is fired for all changes. However, it's fired immediately after it becomes safe if the change occurs during unsafe. 01:07:11 The alternative to not firing beforeinput in those cases is to explicitly state that the event is not cancelable in those cases. Then the 'beforeinput' event could be fired asynchronously and not cause problems. 01:07:28 (I think we've all learned a lot today--this is great.) 01:08:10 It's the same amount of work to spec: (1) don't fire these events in these situations vs. (2) these events are not cancelable in these situations 01:08:25 My preference, is not to have "magical" cancelability, but to simply not dispatch it under certain conditions. 01:09:29 We already have 'variable cancelability' with beforeinput during composition. 01:09:59 so, beforeinput is cancelable (unless it isn't) :-( 01:11:47 Since beforeinput is cancelable primarily to support being a replacement for 'keypress', we also could simply state that it is only cancelable for key events. I don't know if that's OK or not. 01:12:35 (for user generated key events) 01:12:37 I think it has more utility than that. 01:12:46 Probably. I just wanted to throw that out there. 01:13:17 Perhaps the goal should be to have beforeinput and input pairs (always). And when it's not safe to make beforeinput cancelable, then it becomes non-cancelable. 01:14:01 I like having beforeinput and input always occurring in pairs. I'm perfectly happy with it being non-cancelable to avoid problems. 01:14:02 (non-safe could be defined in terms of already being in a beforeinput event handler... 01:14:17 (or being in any script at all) 01:14:37 The trick will be to write that into the spec in a clear and understandable way. 01:14:47 Anyway, it's after 6pm. 01:14:57 Yep. Great progress today. 01:14:59 'Til next week then? 01:15:08 Yep, see you next week! 01:15:31 sgtm. 01:15:35 thanks! 01:15:44 See you! 01:16:30 -garykac 01:16:32 -[Microsoft] 01:16:34 RWC_WAPI(D3E)8:00PM has ended 01:16:34 Attendees were [Microsoft], +1.425.936.aaaa, garykac 01:16:51 Zakim, [Microsoft] is me 01:16:51 sorry, Travis, I do not recognize a party named '[Microsoft]' 01:17:03 me because the conference is over :( 01:17:10 yeah. 01:17:17 RRSAgent: make logs public 01:17:29 jungkees has joined #webapps 01:17:34 RRSAgent: please make the minutes 01:17:34 I have made the request to generate http://www.w3.org/2014/04/30-webapps-minutes.html Travis 01:17:54 Zakim, bye! 01:17:54 I don't understand 'bye!', Travis 01:17:58 Zakim, bye 01:17:58 Zakim has left #webapps 01:18:36 RRSAgent: are logs public 01:18:36 I'm logging. I don't understand 'are logs public', Travis. Try /msg RRSAgent help 01:18:56 RRSAgent: make logs public 01:43:54 krijnhoetmer has joined #webapps 02:08:01 krijnhoetmer has joined #webapps 02:20:31 lmclister has joined #webapps 03:30:01 jcraig has joined #webapps 03:46:04 lmclister has joined #webapps 04:17:21 lgombos has joined #webapps 06:00:58 jcraig has joined #webapps 06:17:26 anssik has joined #webapps 06:32:45 lgombos has joined #webapps 06:47:42 xiaoqian has joined #webapps 07:03:23 dom has joined #webapps 08:00:19 richt has joined #webapps 08:07:22 xiaoqian_ has joined #webapps 08:12:00 darobin has joined #webapps 08:25:44 xiaoqian has joined #webapps 08:49:15 Lachy has joined #webapps 09:40:57 smaug has joined #webapps 09:42:47 xiaoqian_ has joined #webapps 10:11:33 abarsto has joined #webapps 10:25:15 karl has joined #webapps 11:01:44 chaals has joined #webapps 11:22:10 skddc has joined #webapps 11:59:22 smaug has joined #webapps 12:00:37 chaals has joined #webapps 12:35:55 lgombos has joined #webapps 13:51:17 anssik has joined #webapps 14:10:48 karl has joined #webapps 14:30:40 Lachy has joined #webapps 14:44:38 MikeSmith, darobin, can one of you create a new "push-api" project under https://github.com/W3C ? or is there list or such I should use for the request? 14:50:03 ArtB: https://github.com/w3c/push-api 14:50:33 thanks MikeSmith - UDaMan!! 14:52:25 ArtB: cheers 15:04:04 chaals has joined #webapps 15:43:19 richt has joined #webapps 15:44:29 jsbell_ has joined #webapps 15:57:21 lmclister has joined #webapps 15:58:11 lgombos has joined #webapps 15:58:29 sicking has joined #webapps 16:29:38 glenn has joined #webapps 16:40:12 chaals has joined #webapps 17:08:38 jcraig has joined #webapps 17:26:50 Lachy has joined #webapps 18:19:00 lgombos_ has joined #webapps 18:33:21 plh has joined #webapps 19:25:23 chaals has joined #webapps 20:12:46 glenn has joined #webapps 20:27:16 sicking has joined #webapps 20:56:46 glenn has joined #webapps 21:19:00 abarsto has joined #webapps 21:24:31 sicking has joined #webapps 21:51:32 lgombos_ has joined #webapps 21:57:31 glenn has joined #webapps 22:00:13 chaals has joined #webapps 22:05:26 sicking has joined #webapps 22:39:33 lgombos_ has joined #webapps 22:58:16 glenn has joined #webapps 23:00:11 karl has joined #webapps 23:33:20 glenn has joined #webapps 00:03:25 lgombos_ has joined #webapps 00:06:51 lmclister has joined #webapps 00:32:42 lgombos_ has joined #webapps 01:00:33 skddc_ has joined #webapps 01:02:40 lmclister has joined #webapps 01:43:11 glenn has joined #webapps 01:49:05 karl has joined #webapps 01:57:26 karl has joined #webapps 03:02:09 jcraig has joined #webapps