01:01:22 RRSAgent has joined #webapps 01:01:22 logging to http://www.w3.org/2013/12/04-webapps-irc 01:01:32 Zakim, this meeting spans midnight 01:01:33 I don't understand 'this meeting spans midnight', Travis 01:01:38 rrsagent, this meeting spans midnight 01:02:06 Present+ Travis_Leithead 01:03:18 garykac has joined #webapps 01:03:41 fjh_ has joined #webapps 01:03:48 + +81.36.384.aaaa 01:04:06 hi folks! 01:04:26 Hello, Travis 01:04:27 kochix has joined #webapps 01:04:32 muted mine 01:05:07 Agenda+ Talk about preparing for LC 01:05:34 + +1.425.893.aabb 01:06:00 Gary present? 01:06:20 Hallo 01:06:20 Zakim, +1.425 is garykac 01:06:20 +garykac; got it 01:06:28 Present+ garykac 01:06:33 Present+ masayuki 01:06:43 Present+ kochix 01:06:48 a? 01:06:51 agenda? 01:07:11 agenda+ bug review? 01:07:27 lgtm 01:07:28 More items to add to the agenda? 01:07:36 agenda- 01:07:54 zakim, first agenda item 01:07:54 I don't understand 'first agenda item', Travis 01:08:27 I'd like to discuss https://www.w3.org/Bugs/Public/show_bug.cgi?id=23908 today. 01:09:12 agenda+ bug 23908 (key value of printable keys w/meta) 01:10:06 agenda- 1 01:10:46 Our co-chair has informed us that we can publish again in december up until the 7th. 01:10:59 ... after that there is an end-of-year blackout for publishing stuff. 01:11:15 ... If we want to get a LC out for our D3E spec, we must be ready to do so quickly. 01:11:33 ... I see 19 bugs open in bugzilla for our component 01:11:42 ... https://www.w3.org/Bugs/Public/buglist.cgi?component=DOM3%20Events&list_id=30204&product=WebAppsWG&resolution=--- 01:12:03 Well... 01:12:12 I merged in all of the stuff from UI Events 01:12:20 So we have a first draft of all that. 01:12:31 Most of the remaining bugs seem minor (I think) 01:12:50 We should go through them to see which ones require discussion so that we can resolve them now. 01:13:05 I think we'd need to "sign off" by this Friday for this to be possible. 01:13:13 And 01:13:26 I would like it if people could review the sections that have changed 01:13:39 Namely: the keyboard layout section 01:14:14 and the updated initialization/constructor stuff 01:14:30 I think if it's just the 4 of us that should agree that we'd be ready by friday, then we could probably all do a review in the next few days. 01:15:05 I'll be going though it again as well. 01:15:21 Because while I "wrote" it, a lot of the recent changes were merging the old text with the new text. 01:15:32 masayuki: and kochix: what do you think? 01:15:33 I want to make sure that the text flows nicely. 01:15:45 and that there isn't anything obvious missing. 01:16:11 We'll probably need to start an email thread in order to track these issues this week. 01:16:39 CompositionEvent looks good 01:16:41 kochix: Believes what he have now is OK. 01:16:46 s/he/we 01:16:55 Updated section: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#keys 01:17:13 agenda? 01:17:20 agenda- 2 01:17:47 Let's do a quick scan of the existing bugs. Perhaps we can knock out a few. 01:17:57 https://www.w3.org/Bugs/Public/show_bug.cgi?id=22073 01:18:05 garykac: I have notes on this... 01:18:11 I'm still reading the new ED carefully, and I'm filing issues on bugzilla. 01:18:24 masayuki: excellent. 01:19:19 For 22073, we discussed this in Tokyo. 01:19:21 So, I'm still not sure if current ED is enough for LC. 01:19:34 lgombos__ has joined #webapps 01:20:04 garykac: It would be nice to get this out in December, but there's always Jan. 01:20:31 masayuki: Meaning there are still bugs to file, right? 01:20:40 It would be nice to resolve all the bugs before doing another LC. 01:20:47 I agree. 01:20:54 I think that we're in good shape to hit early January. 01:20:59 Travis: I think so. 01:21:18 And I would feel more comfortable giving the text more time to be reviewed for typos and readability. 01:21:23 Then perhaps we shouldn't be too agressive to finish this week. 01:21:25 sgtm 01:21:36 We should let Arthur know 01:21:45 I can do that. 01:22:08 We should ask for the first available date in Jan. 01:22:18 ah, one thing, please remove 2 references to 'inputmode' in beforeinput event. 01:23:35 There were only 2 references to inputmode? 01:23:56 I think so, 01:24:15 in 'beforeinput' and 'input' tables, 2 references of 'with inputmode set' 01:24:40 Refresh the ED - I've updated the spec to remove these. 01:25:19 thanks 01:25:34 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23167 01:25:48 garykac: 01:25:59 ... 23912 fixed. 01:27:03 For the TV keys... 01:27:22 We may want to move those into UI Events (or some other doc) 01:27:54 We're going to try to make a stab at it, but it is really complex and we'll likely have to release a follow-up document as well. 01:28:55 But we can probably add a 'TV' key now, but getting all the other TV remote keys is not likely. 01:29:43 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23186 01:30:13 I've already updated to spec to add "If non-null" 01:30:58 ms2ger says that current implementations currently allow null and don't throw an exception. 01:32:19 So this is really documenting the current state of affairs with browsers. 01:33:26 ms2ger's tests show that these apis always succeed (even if null is passed) 01:33:52 ... where "these apis" mean addeventlistener and removeeventlistener 01:34:08 garykac: is pushing a change out to address this now. 01:34:56 Fix for 23186 has been pushed. 01:34:59 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23257 01:36:33 I closed it. 01:36:35 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23258 01:37:26 Travis is closing this bug because the events have changed a lot recently 01:37:56 I resolved mine won't fix. 01:37:57 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23748 01:38:05 ok, i'll revisit 23258. 01:38:26 garykac: I will be fixing this, but haven't got to it yet. 01:38:30 I'll be fixing 23748 to refer to the table. 01:38:40 lgombos__ has joined #webapps 01:38:46 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23750 01:39:12 We discussed that (ScrollLock) in Tokyo and Nakano-san convinced me that it makes sense to add it as a modifier. 01:39:29 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23886 01:40:16 masayuki: in comment 1, you refer to "example 30" 01:40:23 ... is this from the spec? 01:40:56 Agreed that '' is the right answer since that's what gets inserted. 01:41:12 garykac: I think it's example 34. 01:41:12 (and Example 30 is now Example 34 since 4 more examples got added earlier) 01:41:45 Things like DeadAcute + m should produce 2 chars: `m 01:42:02 I *believe* that's what we see on all platforms, but we need to check/verify. 01:42:28 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23906 01:43:17 This idea comes from XUL which is Mozilla internal API. 01:43:33 We should think about 23906 in the context of 22073 since they seem related. 01:43:52 I believe that if web apps want to implement their own shortcut key, this is useful. 01:43:59 If we have an accelKey, then do we want people to use osKey? 01:44:29 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23907 01:45:12 garykac: I don't think so. Even if web apps need to know the OS key state, there is getModifierState(). 01:45:19 How do webapps determine now if a keydown generates text. 01:47:13 Perhaps this is a feature that we can think more extensively about in UIEvents? 01:47:20 ... does it need to go into DOM3? 01:48:09 I'd like to move this to UIEvents. masayuki what do you think? 01:48:10 not necessary for D3E, it's okay it's in UIEvents. 01:48:28 It's an interesting problem... 01:49:10 23908 is an interesting case as well 01:49:35 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23908 01:49:59 I'm implementing KeyboardEvent.key for printable keys on Gecko, but bug 23908 blocks it on Mac. 01:50:14 So, I hope we decide the answer of this today. 01:50:38 masayuki: what is your preference here? 01:50:57 (On windows, I don't have a preference ;-) 01:51:11 We'll need to create some tests for this as well (since it sounds a bit bizarre). 01:52:01 Travis: I think that the modified key value, i.e., ASCII character is better. Even though the behavior is different from Ctrl key is pressed. 01:52:29 because the printable key's "function" is really changed by pressing command key press. 01:53:09 Dvorak switches from Dvorak -> QWERTY when the command key is pressed? 01:53:28 Especially, Dvorak-QWERTY keyboard layout users don't want web apps handles the key as Dvorak layout while pressing Command key. 01:53:29 But a French keyboard doesn't change the layout from AZERTY to QWERTY. 01:53:37 garykac: yes 01:54:30 shortcut keys of apps for English language users are designed for QWERTY. Therefore, Dvorak layout isn't useful for shortcut keys. 01:54:41 Is that just a weird behavior of Dvorak to deal with the fact that the keycaps don't match the layout. 01:54:51 Some Mac's Dvorak users like this special layout. 01:55:27 If the OS/keyboard-layout went through the trouble to do this, then it's probably nice to support it. 01:55:32 Non-ASCII keyboard layout such as Arabic keyboard layout also has same issue. 01:56:15 So an Arabic keyboard generates QWERTY values when the command key is pressed? 01:56:17 Pressing command key swtches the printable keyboard layout to QWERTY. 01:56:21 I've never tried that... 01:56:51 garykac: yes. You can confirm it with keyboard viewer of Mac OS X. 01:56:51 en-US? (not en-UK or anywhere else) 01:57:13 I think it's en-US. 01:57:28 IIRC, though. 01:58:16 According to Keyboard viewer... 01:58:27 cmd-a produces 'a' 01:58:36 cmd-shift-a produces 'a' (also lowercase) 01:58:42 for en-US 01:58:48 For Arabic 01:59:08 cmd-ش produces 'a' 01:59:31 cmd-shift-ش produces 'A' (uppercase) 01:59:35 This makes me sad 01:59:41 Oh... 02:01:12 My preference is for whatever the OS gives us easily. 02:01:28 I presume that the OS is doing things for a good reason. 02:01:53 And I'm not sure how to map this equivalent into Windows or Linux. 02:02:43 garykac: I don't think that Windows and Linux need to do same behavior since Command key is a special modifier of Mac OS. 02:04:13 We should take a break. 02:04:17 agenda? 02:04:24 agenda- 3 02:04:28 Win/Super/Hyper shouldn't cause text input. So, the printable key values should be unmodified key value except Shift. 02:04:43 When should we meet again? 02:04:55 I won't be available in two weeks (or three weeks) 02:05:07 I can meet again next week though it might be too soon? 02:05:23 Next week sounds good. 02:05:31 SGTM 02:05:40 OK. Next week it will be. 02:05:40 That way we can get feedback 02:05:52 We've made great progress on the bug list. Let's keep it up. 02:05:52 Hopefully everyone will have had time to go through the updates. 02:06:02 Please file more bugs as we find issues. 02:06:12 Yeah. 02:06:23 kochix: Looking into next draft of IME API. 02:06:34 ... working with JianfengLi (Microsoft) 02:06:54 ... hoping to close some bugs before dec. 7 02:07:18 garykac: Could you give your idea for bug 23908 in the bug if you're still thinking the answer? 02:07:46 Last Call? 02:07:53 Anything else for this meeting? 02:08:13 masayuki: for 23908 I don't have strong feelings either way. We should try using whatever the OS gives us easily. It doesn't sounds like it's worth adding a lot of special purpose code to handle that case. 02:09:02 kochix: Do you need anything else in the DOM3 spec for the IME spec work? 02:09:16 garykac: Thanks, then, I'll use the ASCII characters while command key is pressed. 02:09:27 Let me know if there's anything else. 02:09:28 With that, I think we are adjurned. 02:09:30 masayuki: sgtm 02:09:33 Bye everyone! 02:09:37 See you next week. 02:09:37 good byte 02:09:45 oops 02:09:57 -garykac 02:09:58 See you. 02:09:59 -[Microsoft] 02:10:14 rrsagent, please make the minutes 02:10:14 I have made the request to generate http://www.w3.org/2013/12/04-webapps-minutes.html Travis 02:10:23 - +81.36.384.aaaa 02:10:25 RWC_WAPI(D3E)8:00PM has ended 02:10:25 Attendees were [Microsoft], +81.36.384.aaaa, +1.425.893.aabb, garykac 02:10:39 RRSAgent: please make logs public 02:14:33 rrsagent, bye 02:14:33 I see no action items