00:06:03 RRSAgent has joined #webapps 00:06:03 logging to http://www.w3.org/2013/10/16-webapps-irc 00:06:18 Zakim this is DOM3 00:06:28 Zakim, this is DOM3 00:06:28 ok, Travis; that matches RWC_WAPI(D3E)8:00PM 00:06:43 RRSAgent, this meeting spans midnight 00:06:53 Present+ Travis 00:07:17 Hallo Travis 00:07:46 Hello, Travis, Garykac 00:08:12 + +1.650.390.aaaa 00:08:13 - +1.650.390.aaaa 00:08:13 + +1.650.390.aaaa 00:08:42 Present+ garykac 00:09:07 Present+ masayuki 00:09:35 Agenda: TPAC arrangements 00:09:45 zakim, +1.650 is garykac 00:09:45 +garykac; got it 00:09:49 Agenda: Prep for a new spec release before TPAC 00:10:58 The deadline for CfC to publish a spec before TPAC is October 28th 00:11:04 For TPAC, I'm arriving in HK on Sunday. And then I'll be traveling to Tokyo on Wednesday night. 00:11:36 I'll be in Tokyo until Sunday. If Thu or Fri work for Masayuki, then we should try to get together at that time. 00:11:40 For TPAC, I'm arriving in ShenZhen on Sunday, and staying through Saturday morning. 00:12:06 For webapps, the interesting stuff is on Mon/Tue 00:12:14 WebApps meets Mon/Tues, HTML is Thurs/Friday 00:14:24 Let's open the spec, then start reviewing it from the bottom-up. 00:15:12 Gary is pushing an update to the spec now--stay tuned 00:17:24 Update complete, please reload the spec if you haven't already. (Issue 5 should be expose ticks in wheel event) 00:17:49 Starting with issue 22 at the bottom... 00:18:07 starting with issue 22 ("basic mobile phone keys") at the bottom 00:18:37 Do we want to have a section with mobile phone keys? 00:18:48 Or do we want to have that in a separate addendum document? 00:19:11 I wouldn't want the spec to be delayed waiting for these keys, but they certainly would be nice to have 00:22:02 We should try to make a stab at including them, but if takes too much time we should punt. 00:22:25 We don't want to block on this. 00:22:35 Next issue 21: multimedia keyboard. 00:24:16 On Windows, browser can dispatch keydown events for multimedia keyboard's keys at least. On Linux, they are defined by GDK. But I'm not sure if they are actually used. 00:25:03 Would it be better to have LaunchApp1 ... LaunchApp12 or LaunchMail, LaunchBrowser, LaunchXxx ? 00:25:27 There's some overlap (unfortunately) between things like LaunchApp2 and LaunchCalculator 00:26:56 With the GDK definitions, people can remap keys to use the values. 00:26:58 LaunchApp1..12 seems easier for a windows implementation, not sure how Linux would handle this. 00:27:18 App1 .. App12 is the easiest, but then I'm not sure about the best way to handle the GDK definitions. 00:28:25 Issue 20 and 21 are the same issue, right? 00:28:56 Travis: see the bug's comment 0. They are different. 00:29:20 garykac: We could define them generically (numbers), and then suggest how GDK would map their specific app commands. 00:29:28 We could define App1..App12 and then have suggested apps for each number (App2 = Calculator, ...) 00:29:36 ... this works for 1 and 2 which are psuedo-defined anyway. 00:30:03 Actually, there are probably more than 12... 00:30:40 I'm going to write that up to see how it looks and then solicit comments. 00:30:46 Sounds good. 00:31:03 Next issue 19.. 00:32:32 The reason was, there was .char, I think. 00:32:59 For issue 19, why do we use "DeadAcute" instead of the Unicode codepoint? 00:33:25 I think that it's okay to use Unicode comibing characters instead of DeadXxx. 00:34:04 So DeadAcute would become \x0301. 00:35:25 This is not as pretty in the code as the "DeadAcute", but there are a lot more combining characters than the short set that we have. 00:40:52 I like the friendly names, but the unicode code points is more general. 00:41:27 No resolution here yet. 00:41:28 Let's think about it a bit more and revisit this next time. 00:42:02 Next issue 18. 00:42:10 For the Eisu key, I think we should call it "Eisu" since that's the most common name for it. 00:42:21 I have no context on this, perhaps masayuki can weigh in? 00:42:24 I don't think there's any value coming up with another name for it. 00:42:55 Resolve to name the key Eisu then? 00:43:20 Also see issue 16 - Zenkaku and Hankaku are probably better names for these keys than fullwidth/halfwidth since that's how they are defined in most (all?) OSs. 00:43:41 On JIS keyboard for PC, there is also Eisu key, but it may work different from Mac's Eisu key. Should we use same name for them? 00:44:37 garykac: I agree with Zenkaku/Hankaku are better name. 00:44:43 HTML5's input mode: http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute 00:45:18 has keywords, "full-width-latin", but no half-width anything at the moment. 00:45:37 Travis is checking to see if there's another W3C spec that uses the names fullwidth/halfwidth. If so, it makes sense to be consistent with that other spec. If not, I think zenkaku/hankaku work better. 00:46:46 I don't think that the HTML5 spec presents a compelling argument for keeping fullwidth/halfwidth 00:46:47 It depends on Zenkaku/Hankaku key switches if they actually change the inputmode to fullwidth/halfwidth characters. 00:47:30 I meant it depends on the environment. 00:47:50 OS or IME framework or IME. 00:47:57 I think HTML5's input mode is a helper for IME. 00:48:19 As far as the names go, I don't have a strong opinion. 00:49:18 Another argument for zenkaku and hankaku is that ZenkakuHankaku sounds better than FullWidthHalfWidth ^_^ 00:49:30 and Issue 15, if there's a key for it, I'd like to include it. 00:50:26 I'm not sure if there's a real key equivalent for IMEToggle? Does the OS grab it before the browser has a chance to see it? 00:51:04 Anyway, if we find these keys, I'll add them. But I'm going to look for evidence first (this issue is a placeholder reminder for me) 00:51:05 I think that KanaMode and KanjiMode indicates the result of the keypress, however, in most environment, we cannot know what happes with the key because it may depend on IME settings. 00:52:12 OK. I'll hold off on them and we can add them later if needed. 00:52:25 If we do add these keys, but can't implement them, then they can be labelled "at risk" for the CR for DOM 3 Events, and we can remove them later if they are un-implementable. 00:52:48 On all platforms, we can catch every native key event before IME handles it. However, on Windows, current implementations handles it after IME handles it. 00:52:48 For issue 14, I've seen both PowerOff and PowerDown. Is there a distinction or are they the same thing? 00:54:01 They seem like the same thing. 00:54:09 I'll merge these keys unless we find evidence that they should be separated 00:54:43 See https://www.w3.org/Bugs/Public/show_bug.cgi?id=21118#c3 00:54:59 For issue 13, Sleep, Hibernate and Suspend, we should add text describing the difference between them. 00:55:57 Ideally, these keys would cause a separate Sleep or Hibernate event that would be handled. 00:56:20 Sleep is generally the "lightest" sleep (wake and be ready at a moment's notice. 00:56:36 I'm not sure if it makes a lot of sense to have them here, but they are actually defined keys 00:56:45 Suspend, may actually mean that the system is not shutting down, but that the app is being suspended--could be confusing. 00:57:39 Might just want to add them with a note saying they are included for completeness and that their behavior might overlap 00:57:39 Travis says that we could add a note "included for completeness". Which is a good idea. 00:58:18 for issue12, the text should read MediaPause (not MediaPlay) 00:58:53 Oh nevermind. 00:59:21 I think the Pause key is a leftover from older days and shouldn't be used for media apps. 00:59:49 Should we meet next week? 01:00:06 Yes, Play and Pause are legacy keys for old non-PC systems. 01:00:23 Yes, I'd like to meet next week. 01:00:25 Good. That's what I thought. 01:00:34 (The 22nd). 01:00:40 We want to try to CfC by the 28th. 01:00:41 Okay. 01:01:06 We should plan on making last-minute polish on the spec, and try to issue the CfC for publication in that coming week. 01:01:11 Should we leave any of the "issue"s in the spec for the CfC, or do we need to remove all of them? 01:01:37 I wonder if it makes sense to leave markers for areas that we want people to review or comment on. 01:01:54 I think we want to remove them all... 01:02:07 But I want to call people's attention to the areas of the spec that have had major changes. 01:02:19 We'll probably have to do that in the announcement email 01:02:50 Will we meet in Tokyo on Oct 31th or Nov 1th? 01:03:06 We should add a "general changes" section (F.3) to direct folks to what's new 01:03:32 TPAC is Nov 11-15 01:04:06 After next draft is published, I'll modify Gecko's implementation. Then, I'll feedback new issues if there are. 01:04:20 That sounds great. 01:04:36 I'll be in Tokyo Thu 14 Nov - Fri 15 Nov (actually until Sun 17 Nov) 01:04:42 Recap on action items... 01:04:49 masayuki: Sounds great! 01:05:17 garykac: Okay, I'll book the days. 01:05:37 garykac: should be able to propose solutions to issues 11-22 (key name changes) 01:05:39 One AI I have on hold from last week is moving locale into UI Events. Do we still want to hold off, or should we do that now? 01:06:56 masayuki: which day works better for you, Thu or Fri? Pick one and let us know. I don't know if Kochi has a preference. 01:07:18 Travis will follow-up with Kochi on the potential removal of locale from the spec. 01:07:24 garykac: Either is okay, but Thu is better for me. 01:08:21 Let's plan on Thu then. 01:08:23 garykac: To produce a first draft of the CfC document with all issues noted for review, rather than being open. 01:08:45 See you all next Tue 01:08:51 See everyone next week! 01:08:52 -garykac 01:08:55 See you! 01:09:08 -[Microsoft] 01:09:09 RWC_WAPI(D3E)8:00PM has ended 01:09:09 Attendees were [Microsoft], +1.650.390.aaaa, garykac 01:09:27 rrsagent, publish the minutes 01:09:27 I have made the request to generate http://www.w3.org/2013/10/16-webapps-minutes.html Travis 01:09:35 rrsagent, make logs public 01:11:43 RRSAgent: bye 01:11:43 I see no action items