23:53:21 RRSAgent has joined #webapps 23:53:21 logging to http://www.w3.org/2013/06/04-webapps-irc 23:53:36 RRSAgent, this meeting spans midnight 23:54:16 zakim, this is dom3 23:54:16 travis, I see RWC_WAPI(D3E)8:00PM in the schedule but not yet started. Perhaps you mean "this will be dom3". 23:54:29 zakim, this will be dom3 23:54:29 ok, travis; I see RWC_WAPI(D3E)8:00PM scheduled to start in 6 minutes 23:56:28 agenda+ New repository for editor's drafts (CVS->Hg) 23:56:47 agenda+ Summary/overview of recent updates (formatting/typos) 23:57:07 agenda+ Overview of proposed changes (adding section on 'input' and 'beforeinput') 23:57:21 agenda+ Use cases for locale attribute 23:57:38 agenda+ Reviving 'textinput' event? 23:59:30 agenda+ Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) 23:59:56 RWC_WAPI(D3E)8:00PM has now started 00:00:03 +[Microsoft] 00:00:15 Zakim, microsoft is me 00:00:15 +travis; got it 00:00:17 garykac has joined #webapps 00:00:22 Hi gary! 00:00:23 kochi_ has joined #webapps 00:00:26 Hallo! 00:00:26 hi 00:00:34 real_wez has joined #webapps 00:00:35 We'll be dialing in in a sec. 00:00:57 scribe: travil 00:01:08 scribe: Travis 00:01:13 scribeNick: Travis 00:01:26 +[IPcaller] 00:01:32 + +1.425.893.aaaa 00:01:44 zakim, ipcaller is kochi_ 00:01:44 +kochi_; got it 00:02:04 zakim, 1.425 is garykac 00:02:05 sorry, travis, I do not recognize a party named '1.425' 00:02:12 zakim, +1.425 is garykac 00:02:12 +garykac; got it 00:02:32 zakim, who is on the phone? 00:02:32 On the phone I see travis, kochi_, garykac 00:02:53 agenda 00:03:06 http://www.w3.org/2008/webapps/wiki/DOM3Events 00:03:15 zakim, what is the agenda? 00:03:15 I see 6 items remaining on the agenda: 00:03:16 1. New repository for editor's drafts (CVS->Hg) [from travis] 00:03:16 2. Summary/overview of recent updates (formatting/typos) [from travis] 00:03:16 3. Overview of proposed changes (adding section on 'input' and 'beforeinput') [from travis] 00:03:16 4. Use cases for locale attribute [from travis] 00:03:17 5. Reviving 'textinput' event? [from travis] 00:03:18 6. Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) [from travis] 00:03:42 agenda+ Discuss spacebar 00:04:49 zakim, move to agenda 1 00:04:49 agendum 1. "New repository for editor's drafts (CVS->Hg)" taken up [from travis] 00:04:59 So.. starting from the top... 00:05:18 We are using the new repository 00:05:26 It's a bit flaky at times 00:05:47 It often fails to authenticate 00:05:57 But the it starts working again a few hours later 00:06:25 I' 00:06:40 I've converted the spec to use respec everywhere 00:07:17 Which means that it's autonumbered now 00:07:21 Link to new ReSpec edition: https://dvcs.w3.org/hg/dom3events/raw-file/6cc9e60bf4b1/html/DOM3-Events.html 00:07:24 and we use respec formatting for the IDL 00:07:42 this organizes the content a little bit more nicely 00:07:47 especially with the IDL stuff 00:08:09 previously the IDL definitions were spread in multiple sections, now we only have to define it in one place 00:09:23 I also added a key table generator. the content of the table is now generated via javascript 00:09:35 Looks great--I don't notice any significant changes... :0) 00:10:31 abarsto has joined #webapps 00:11:21 garykac: need to make the spec look like an editor's draft, instead of a working draft. 00:11:45 All the changes have been merged into the top-of-tree to make a new baseline 00:12:10 zakim, next agendum 00:12:10 agendum 2. "Summary/overview of recent updates (formatting/typos)" taken up [from travis] 00:12:28 garykac: Fixed a couple of typos... 00:12:41 And a couple of grammar issues and capitalization 00:13:17 zakim, move agendum 6 to 4 00:13:17 I don't understand 'move agendum 6 to 4', travis 00:13:40 zakim, next agendum 00:13:40 agendum 3. "Overview of proposed changes (adding section on 'input' and 'beforeinput')" taken up [from travis] 00:14:06 There are a bunch of places in the spec that refer to 'input' events replace 'keypress' 00:14:14 But 'input' is not properly defined in any spec 00:14:33 On the ML, someone said that they expected it to be in this spec. 00:14:47 Which was a great surprise to those of us working on this spec 00:15:31 however, it makes some sense to include it here if we're going to going to rely on it to replace 'keypress' 00:15:35 zakim, agenda order is 3,5 00:15:35 ok, travis 00:15:41 I'm not convinced that input/beforeinput is the right way to solve this 00:16:14 They are geared toward notifying of changes to the contents of input elements, IIUC 00:16:26 Fundamentally they are not tied to text input 00:16:39 I think we need to make sure the spec includes a suitable replacement for 'keypress' 00:16:39 I think we're agreed we want a replacement for keypress 00:17:02 The old textInput spec seems a better fit for that than input 00:17:36 FYI I'm seeing old textInput spec at http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#events-textevents 00:17:42 What do input and beforeinput contain if the element isn't a text input element, for example? 00:19:03 Gary points out that input and beforeinput may only have been intended to apply to text editing fields, originally 00:19:39 One point arguing against textInput has been that e.g. speech recognition should be distinguishable from keyboard text input 00:19:47 I think that beforeinput was indended to be for editing, yes. 00:20:13 The input event is basically a change notification for input/textarea elements. 00:20:39 The only context it conveys is the 'target' , where to check for the updated text. 00:21:00 If input/beforeinput are text-element-specific then I'd be more comfortable with using beforeinput to convey newly-entered characters 00:21:13 The textInput carried all the data from the KeyboardEvent. 00:21:40 However, there's the question of how non-text-input elements would receive character data if entered, e.g.
00:22:09 The element has to be focusable... right? 00:22:35 If you create a
and add event listeners for "keydown" etc then can yoiu also get "beforeinput" so as to see the character input? 00:22:37 It sounded like input/beforeinput were intended for editing, so I'm not sure if a
would receive them 00:22:52 input/beforeinput make sense when actual text gets added--but not for generic elements... 00:23:43 Gary suggests starting a thread on the broader mailing list around the rationale for preferring input/beforeinput vs textInput 00:23:56 ...and bring up these issues 00:23:58 Is there any reason why we wouldn't consider back 'keypress'? 00:24:09 Historically it was under-specified 00:24:09 garykac: We could specify it... 00:24:35 Plus, we may receive multiple characters for a single keypress, which the existing keypress w/ char field doesn't really fit 00:25:16 i.e. if we use it to convey entered text, it doesn't then match an individual keypress, so it's mis-named 00:25:52 Plus, if we have e.g. textInput then that can in principle be generated by other input than keyboard, e.g. speech recognizers 00:26:02 Without confusing folks by the name 00:26:23 There's a lot of exising documentation on the web that describes how to use 'keypress' and it covers the old/broken version. So there might be confusion if we redefine it. 00:26:31 True 00:26:50 So, textInput means that input is being sent--not necessarily that input is being recieved. 00:27:00 But then how prevalent are the "broken" implementations - are the various browsers at least consistent? 00:27:32 travis: More that text input has been generated, somehow, not necessarily via keyboard input 00:27:54 e.g. you might get text input by an on-screen keyboard, or from speech recognition, OCR, etc 00:28:07 marcosc has joined #webapps 00:28:32 Gary says that keypress implementations are not consistent wrt ordering of events, etc - we'd have to break existing impls to define something consistent 00:28:36 That seems bad to me! 00:28:38 allowing non-edit element to get textInput event fits the model that IME API assumes 00:29:06 You mean that non- elements can receive entered text? 00:29:08 If we define 'keypress' now, we'll end up breaking at least one current implementation and there are certainly webapps that depend on current browser behavior 00:29:14 real_wez: yes 00:30:18 Gary also mentions that looking for the "input" event in docs is a pain because the name is so generic! 00:30:41 (I think that's also true for the name "UI Events") 00:30:43 ;) 00:30:53 Got to search with "named input" :-) 00:31:16 Can we change the spec to "DOM4 UI Events" or "D4E UI Events" or something more helpful? 00:32:27 So, do we have an opinion on adding 'input'/'beforeinput' vs.bringing textinput back? 00:32:52 real_wez: I think it would be great to have both input/beforeinput in the spec as well as textinput... 00:33:03 My preference would be to add specification of beforeinput and input to D3E, independent of the input vs textInput question 00:33:06 Yay 00:33:10 I am double-scribed 00:33:16 garykac: I'm worried about the delay that will cause to the spec. 00:33:38 I would rather punt to D4UIEvents unless we need to include it in DOM3 in order to cover a replacement on 'keypress' 00:34:53 zakim, next agenda 00:34:53 agendum 5. "Reviving 'textinput' event?" taken up [from travis] 00:34:58 zakim, next agenda 00:34:58 agendum 5 was just opened, travis 00:35:16 zakim, move to the next agendum 00:35:16 I don't understand 'move to the next agendum', travis 00:35:21 Questions is about the use-cases for the "locale" field 00:35:25 *question 00:35:29 zakim, next agendum 00:35:29 agendum 5 was just opened, travis 00:35:53 zakim, close this agendum 00:35:53 agendum 5 closed 00:35:54 I see 3 items remaining on the agenda; the next one is 00:35:54 4. Use cases for locale attribute [from travis] 00:35:57 Locale was invented for use w/ textInput so that the source of textInput is clear 00:36:47 the original intention of local was to add context for textinput event 00:36:50 Locale field was then propagated to keydown, keyup, composition*, etc 00:37:41 The intent with 'locale" was to support language-specific spell-check, word suggestions, etc, if I understand correctly? 00:37:51 Locale is a BDP-47 string 00:38:17 Do the IME events specify a subset of these strings? or can any BCP-47 string be present and useful? 00:38:31 It seems like a lot of the BCP-47 strings are too general 00:38:54 kochi sez: locale is useful as a hint 00:39:02 kochi_: I see this as a hint to applications, it's not specific like en-us, but is still useful. 00:39:30 kochi_: For example: spellchecking would see that it's not russian, but english... 00:39:34 Have any browsers implemented 'locale' yet? 00:39:42 IE9 has implemented. 00:39:56 kochi_: Masayuki implemented in Firefox 00:40:18 FF has implementation for Win/Mac 00:43:02 smart quotes (") is a use case for keypress locale 00:43:44 kochi_: So would having 'locale' on textInput not work for that use-case? Would that be too late to see the locale? 00:44:03 Travis_ has joined #webapps 00:44:27 real_wez: should be same for keypress and textInput 00:44:36 kochi_: Are we allowing re-writing of events, e.g. textInput w/ '"' becomes textInput with '>>" in French?> 00:45:15 kochi_: keypress is deprecated; do you mean keydown? 00:45:40 usually modern custom editors listen events in hidden field and can insert different character for rendering text 00:46:05 so users won't see raw (") character typed 00:46:10 zakim, agenda? 00:46:10 I see 3 items remaining on the agenda: 00:46:11 4. Use cases for locale attribute [from travis] 00:46:11 6. Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) [from travis] 00:46:11 7. Discuss spacebar [from travis] 00:46:11 kochi_: Could custom editors listen for textInput, detect the locale, and adjust the characters entered, then? 00:46:29 real_wez: i think so. 00:46:47 I think there's a bit more detail that should be considered... 00:47:12 kochi_: So we don't need 'locale' on keydown/keyup? 00:47:38 real_wez: might be, if textInput is implemented. 00:47:57 kochi_: :D 00:48:03 Question to answer: is the current spec (BCP-47) good enough? It sounds like it is for IME events, but it might not be for keydown/keyup events. 00:48:13 I wonder if it's sufficient to have it only in the CompositionEvents + IME API. 00:49:01 Travis_: if system doesn't have IME at all, no composition events but some apps may want to know whether the locale is French or English, for example 00:49:06 We have to agree (and get the working group to agree) that BCP-47 is good enough. Might be worth a shot. 00:50:32 Gary suggests that for the current use-cases, BCP-47 is overkill - not necessarily a reason to change it, but worth bearing in mind 00:50:43 So, when we go into Last Call for CR, we can mark locale "at risk" meaning we can rip it out without going back to working draft if necessary. 00:50:46 Based on the current use-cases revolving around language-matching 00:50:54 The current spec says that locale is defined as BCP-47, so we should be good there. 00:51:13 zakim, next agendum 00:51:13 agendum 4. "Use cases for locale attribute" taken up [from travis] 00:51:29 zakim, close this agendum 00:51:29 agendum 4 closed 00:51:31 I see 2 items remaining on the agenda; the next one is 00:51:31 6. Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) [from travis] 00:52:15 zakim, take up agendum 7 00:52:15 agendum 7. "Discuss spacebar" taken up [from travis] 00:52:40 Gary raises Masayuki's point about the Spacebar key value; he agrees that 'Spacebar' is a bad name, and more suitable for D4E's 'code' value for that key 00:53:28 There are a lot of X11 keysyms that seem to have been imported from an old font (not keyboard). 00:53:56 Wez recalls that these were related to an old (obsolete) DEC keyboard related to publishing 00:54:29 I don't think we should worry about NBSP, halfwidth space, et al. unless we can find a modern keyboard layout that generated these keys. 00:55:12 What is the specific action for D3E? 00:55:57 Also, the SPACE and the Keypad_SPACE should both generate the same 'key' value (just like the '2' and the Keypad-'2' generate the same value - just with a different location) 00:57:04 For D3E, we need to update the definition for 'key' when the spacebar is pressed 00:57:20 When implementing the key values for various control characters, the question of what to report was raised, as it's somewhat ambiguous 00:57:45 Fundamentally the keysyms Masayuki raised are of two kinds: Space and KP_Space have the same semantic meaning, but are on different physical keys - they can generate the same 'key' and then be distinguished by location. The remaining "space" KeySyms have different meanings to the normal space character, so aren't appropriate for including in 'key' 01:00:16 So, it might be worth giving some of those control codes names (if they don't already in the spec). 01:00:56 Yes, names for the control codes makes sense (even though I'm not sure how to type them) 01:01:41 Next meeting in 2 weeks (June 18) 01:01:45 Same time. 01:01:48 ASCII has the "printable" characters starting from character 0x20 (32) (Space) - the preceding characters are "control" characters. I think it would make sense to use that distinction here, and so have ASCII Printable characters always use the character for the 'key' value, and generate the corresponding character input 01:02:08 zakim, agenda? 01:02:08 I see 2 items remaining on the agenda: 01:02:09 6. Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) [from travis] 01:02:09 7. Discuss spacebar [from travis] 01:02:16 And have non-"ASCII-printable" characters use named 'key' values, e.g. 'Tab', 'Delete', etc 01:02:19 zakim, close agenda 7 01:02:19 agendum 7, Discuss spacebar, closed 01:02:20 I see 1 item remaining on the agenda: 01:02:20 6. Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---) [from travis] 01:02:29 zakim, close agenda 6 01:02:29 agendum 6, Review the bug list (https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---), closed 01:02:31 I see nothing remaining on the agenda 01:02:33 -kochi_ 01:02:37 -garykac 01:03:11 rrsagent, prepare the minutes 01:03:11 I'm logging. I don't understand 'prepare the minutes', Travis_. Try /msg RRSAgent help 01:03:21 rrsagent, make the minutes 01:03:21 I have made the request to generate http://www.w3.org/2013/06/04-webapps-minutes.html Travis_ 01:03:35 -travis 01:03:36 RWC_WAPI(D3E)8:00PM has ended 01:03:36 Attendees were travis, +1.425.893.aaaa, kochi_, garykac 01:04:18 rrsagent, make the minutes public 01:04:18 I'm logging. I don't understand 'make the minutes public', Travis_. Try /msg RRSAgent help 01:05:13 rrsagent, make logs public 01:07:11 Present: garykac 01:07:18 Present: Travis_ 01:07:40 Present: real_wez 01:07:48 Present: kochi_ 01:07:58 rrsagent, please make the minutes 01:07:58 I have made the request to generate http://www.w3.org/2013/06/04-webapps-minutes.html Travis_ 01:22:23 marcosc has joined #webapps 01:26:04 yoichio has joined #webapps 01:56:48 glenn has joined #webapps 02:16:40 marcosc has joined #webapps 02:38:37 kochi_ has joined #webapps 03:10:56 marcosc has joined #webapps 04:05:11 marcosc has joined #webapps 04:30:05 Zakim has left #webapps 04:45:30 sicking has joined #webapps 04:59:27 marcosc has joined #webapps 05:45:21 richt has joined #webapps 05:53:36 kochi_ has joined #webapps 06:14:08 Lachy has joined #webapps 06:16:22 Lachy has joined #webapps 06:22:19 tobie has joined #webapps 06:40:55 Ms2ger has joined #webapps 06:48:54 richt has joined #webapps 06:57:10 marcosc has joined #webapps 07:01:49 Dashiva has joined #webapps 07:11:39 marcosc has joined #webapps 07:16:52 richt has joined #webapps 07:46:37 darobin has joined #webapps 08:08:22 marcosc has joined #webapps 08:21:18 richt has joined #webapps 08:22:37 richt_ has joined #webapps 08:24:17 smaug has joined #webapps 08:28:15 richt__ has joined #webapps 08:28:40 richt has joined #webapps 08:28:59 Lachy has joined #webapps 09:13:47 richt_ has joined #webapps 09:36:32 richt has joined #webapps 09:48:14 marcosc has joined #webapps 09:58:40 abarsto has joined #webapps 10:17:40 glenn has joined #webapps 10:25:41 smaug has joined #webapps 11:21:49 dom has joined #webapps 12:42:47 marcosc has joined #webapps 12:58:01 skddc has joined #webapps 13:08:26 davidb has joined #webapps 13:21:04 fjh has joined #webapps 13:29:31 glenn has joined #webapps 14:04:17 anssik has joined #webapps 14:40:29 marcosc has joined #webapps 14:55:32 smaug has joined #webapps 14:59:50 marcosc has joined #webapps 15:03:18 davidb has joined #webapps 15:05:18 abarsto has joined #webapps 15:37:55 jsbell has joined #webapps 16:14:35 lyle has joined #webapps 17:12:40 dveditz has joined #webapps 17:40:50 glenn has joined #webapps 18:11:19 richt has joined #webapps 19:15:38 richt has joined #webapps 19:20:54 smaug has joined #webapps 19:28:31 davidb has joined #webapps 19:48:24 skddc_ has joined #webapps 19:54:00 chaals has joined #webapps 20:06:00 darobin has joined #webapps 20:12:58 marcosc_ has joined #webapps 20:50:48 glenn has joined #webapps 22:03:47 sicking has joined #webapps 22:24:28 glenn has joined #webapps 22:25:20 schuki has joined #webapps 22:48:24 jsbell has joined #webapps 22:53:43 marcosc__ has joined #webapps 23:02:39 sicking has joined #webapps 23:17:02 lyle has joined #webapps 23:43:54 abarsto has joined #webapps 23:52:12 glenn has joined #webapps 00:12:39 sicking has joined #webapps