22:38:10 <RRSAgent> RRSAgent has joined #webapps
22:38:10 <RRSAgent> logging to http://www.w3.org/2013/05/07-webapps-irc
22:38:32 <ArtB> Meeting: DOM 3 Events
22:38:40 <ArtB> Chair: Travis
22:39:14 <ArtB> Agenda: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0076.html
22:39:25 <ArtB> RRSAgent, make minutes
22:39:25 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-webapps-minutes.html ArtB
22:39:49 <ArtB> RRSAgent, make log Public
22:39:54 <ArtB> RRSAgent, make minutes
22:39:54 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-webapps-minutes.html ArtB
22:53:31 <smaug> smaug has joined #webapps
22:59:07 <Zakim> Team_(webapps)22:36Z has now started
22:59:14 <Zakim> +[Microsoft]
22:59:22 <Travis> Zakim, Microsoft is me
22:59:22 <Zakim> +Travis; got it
22:59:31 <Travis> Zakim, this is DOM 3 Events
22:59:31 <Zakim> sorry, Travis, I do not see a conference named 'DOM 3 Events' in progress or scheduled at this time
22:59:41 <kochi> kochi has joined #webapps
22:59:41 <real_wez> real_wez has joined #webapps
22:59:44 <Travis> Zakim, this is DOM3
22:59:44 <Zakim> sorry, Travis, I do not see a conference named 'DOM3' in progress or scheduled at this time
23:00:29 <Travis> garykac: Call the W3C Bridge instead of the info I sent you...
23:00:46 <Travis> 6177616200
23:01:06 <Travis> zakim, who is on the phone
23:01:06 <Zakim> I don't understand 'who is on the phone', Travis
23:01:09 <Travis> zakim, who is on the phone?
23:01:09 <Zakim> On the phone I see Travis
23:01:10 <Zakim> + +1.425.893.aaaa
23:01:49 <Travis> zakim, +1.425.893 is garykac
23:01:49 <Zakim> +garykac; got it
23:02:08 <Travis> masayuki: You alive?
23:02:25 <masayuki> Travis: Yes. Thank you for inviting me.
23:03:03 <Travis> Scribe: Travis
23:03:10 <Travis> ScribeNick: Travis
23:04:04 <Zakim> +[IPcaller]
23:04:06 <real_wez> Hello all
23:04:32 <Travis> zakim, ipcaller is kochi
23:04:32 <Zakim> +kochi; got it
23:05:10 <garykac> travis: start by creating an agenda
23:05:36 <garykac> travis: then we need to talk about timelines for action items
23:05:53 <garykac> start with spec update
23:05:56 <Travis> Topic: spec update
23:06:02 <garykac> started with existing dom3 spec
23:06:10 <Lachy> Lachy has joined #webapps
23:06:24 <Travis> garykac: ... was being edited by hand. Required tedius changes
23:06:29 <Travis> ... coverted to ReSpec
23:06:35 <Travis> ... (with no changes)
23:06:41 <Travis> ... Then changed to ReSpec IDL
23:06:46 <Travis> ... Fixed some typos
23:07:03 <Travis> ... JS expands out the table now.
23:07:14 <Travis> ... waiting for new repro to be ready
23:07:25 <Travis> ... then we can start adding/explaining existing stuff
23:07:46 <Travis> ... CVS repo is moving to Mercurial for ease/convenience
23:08:33 <Travis> ... masayuki found some errors where some things weren't labelled
23:08:41 <Travis> ... this will put us in a better position moving forward.
23:09:07 <Travis> ... Found 15/20 issues that still need to be filed in bugzilla.
23:09:30 <Travis> ... a couple are significant, I can talk about them here once we get through our other items.
23:10:08 <Travis> ... the ReSpec is sittting locally...
23:10:21 <Travis> ... should be only a few days till it's ready.
23:10:51 <Travis> I'd like to just wait until the Repro is ready to check it in.
23:11:21 <Travis> Anything else on this topic?
23:11:45 <Travis> garykac: Should be it; waiting until spec is ready before filing the next round of issues.
23:11:59 <Travis> Topic: Bugs!
23:12:07 <Travis> https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM3%20Events&resolution=---&list_id=10169
23:12:49 <Travis> I see 27 bugs, plus the 15/20 that Gary will deposit soon
23:13:26 <Travis> I'd like a call for discussion on any of these bugs?
23:13:37 <Travis> masayuki: Do you have any you'd like to talk about?
23:14:13 <masayuki> Yeah, there are a lot of issues for naming .key values.
23:14:46 <masayuki> If browser venderos can name it originally, it will break compatibility between browsers in the future.
23:14:56 <Travis> garykac: We might get into bikeshedding on those...
23:15:04 <Travis> ... are there any larger issues?
23:15:19 <masayuki> Is vender prefixed name better for not predefined key names?
23:15:53 <garykac> I would rather define them in the spec if at all possible.
23:16:17 <Travis> wes: Direction we were thinking with not defined key names is to add them into the spec; vendor prefixes are dangerous because they persist.
23:16:22 <garykac> It's hard to remove vender prefix once the've been added to some implementations.
23:17:07 <Travis> real_wez: One topic to split up the key table into sections.
23:17:14 <masayuki> I think that web apps can remove vender prefix before comparing the values, that is difference from CSS's vendor prefix.
23:17:20 <Travis> ... yes, garykac had some thoughts on how to do this...
23:17:42 <Travis> ... like color keys (red,blue,...) ect. seems reasonable to have a key value for those
23:17:49 <marcosc> marcosc has joined #webapps
23:17:51 <Travis> ... right now, they're just all mixed into the jumbo table.
23:18:00 <Travis> ... garykac wanted to split into sections.
23:18:10 <Travis> garykac: Right now the key table was one gigantic table.
23:18:20 <Travis> ... there was categories, but it didn't help much
23:18:32 <Travis> ... additionally, we're going to want to augment this table over time
23:18:50 <Travis> ... e.g., there's the Android bug to map the keys to Android..
23:19:16 <masayuki> And I want a rule for browser vendoers who want to add new key value. I'd like to suggest that file a bug for new key value before implementing it.
23:19:23 <Travis> ... so having some easy way of adding sub-categories (addendums) to the spec without having to re-publish the w3c spec.
23:19:40 <garykac> Filing a bug for that is a good idea
23:19:43 <Travis> That sounds good.
23:19:51 <real_wez> Agreed
23:19:53 <Travis> garykac: That's how we'd track all these issues.
23:20:13 <Travis> ... if we forgot to add it to DOM3, then we may have to add it to some other place (UI Events?)
23:20:25 <real_wez> The Android keys example is a good one
23:20:41 <real_wez> There are a variety of Android devices
23:20:42 <Travis> ... once we say we are done with DOM3, we are done--there should be some other means to augment.
23:20:46 <real_wez> From different manufacturers
23:20:52 <real_wez> And they all have different keys
23:21:12 <masayuki> FYI: Gecko's .key value mapping table: http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0079.html
23:21:19 <Travis> garykac: We do want these to be interoperable, and just need to come up with a process.
23:21:24 <real_wez> So how do we allow those to be added in a way that's not super painful for vendors, and not super confusing for content?
23:21:31 <Travis> ... we should get a bug filed to create that process.
23:22:20 <Travis> real_wez: It's not just mappings, but new keys as well.
23:22:22 <garykac> action: create bug in Bugzilla to figure out the best way to have addendum key tables (eg: for Android)
23:22:22 <trackbot> Error finding 'create'. You can review and register nicknames at <http://www.w3.org/2008/webapps/track/users>.
23:23:21 <garykac> masayuki: Thanks for sharing the mapping table. We'll be looking at that to make sure the spec covers as much as possible.
23:24:07 <Travis> I see the KeyboardEvent.locale bug...
23:24:13 <kochi> Does the 'locale' issue apply to all inputevent, composition events?
23:24:17 <garykac> The locale field needs to be specified properly in the DOM3 spec.
23:24:17 <Travis> garykac: Yes, it's too general at the moment.
23:24:52 <Travis> real_wez: masayuki made the point that it's not clear when you have a custom layout
23:24:59 <kochi> if so, it also applies to IME API spec.
23:25:04 <Travis> ... if you have users with their own changed keyboard
23:25:08 <garykac> wez: Masayuki brought up point of custom keyboards - what is the proper way to handle that
23:25:17 <Travis> ... if we're relying on that layout and JS to understand layout--makes it much more fragile.
23:25:51 <Travis> garykac: it's a keyboard event, not a core event--applies not to composition event.
23:26:32 <Travis> garykac: locale (we have a bug tracking that)
23:26:33 <masayuki> Travis: composition event has .locale too.
23:26:50 <Travis> real_wez: would we be better off having a way to get the current state of the keyboard?
23:27:01 <Travis> ... a code to keyvalue, low-level API?
23:27:13 <Travis> ... would be harder for implementors.
23:27:46 <Travis> masayuki: Yes, same general problem for composition events too. (It's too general)
23:28:21 <kochi> travis, masayuki: then it also applies to IME API as it is basically combined with composition events
23:28:36 <garykac> ugh. yes. CompositionEvents have locale as well. :-(
23:28:43 <real_wez> If you look at the note on the "locale" field what you see is that it makes clear that it's not necessarily "correct" in a lot of cases
23:29:06 <real_wez> So my question is what is "locale" _intended_ to solve? :)
23:30:23 <masayuki> I tried to implement .locale on Gecko at the end of April. However, on Mac, we cannot get country/area code. So, on Mac, nobody can return "en-US" like IE. Just "en".
23:31:00 <garykac> masayuki: that's sad to hear.
23:31:13 <garykac> we need to have a locale spec that can actually be implemented on all platforms
23:31:41 <Travis> kochi: To predict LTR/RTL key based on locale (another use case)
23:31:46 <glenn> glenn has joined #webapps
23:32:02 <Travis> real_wez: Is it the case that the locale can be associated with the window, not the events.
23:32:08 <Travis> ... does it help?
23:32:10 <garykac> does that help?
23:32:36 <Travis> ... It helps know the state of the input system.
23:32:55 <masayuki> I'm not sure whether we can implement .locale on Linux. I have a hint for that https://bugzilla.mozilla.org/show_bug.cgi?id=680832#c8 but I don't check it actually.
23:33:28 <garykac> We'll want to have a proof-of-concept on each platform before signing off on the locale spec
23:33:58 <Travis> IME API will expose locale as a state object on an input context. Might be worth considering this in the big picture.
23:34:29 <garykac> is the locale exposed by the IME API is a BCP-47 string?
23:34:45 <Travis> kochi: The locale should be BCP47 based. (on the IME API)
23:34:45 <garykac> kochi: it should  be
23:34:45 <kochi> IME API defines it is BCP-47 string
23:35:18 <Travis> garykac: locale might be the riskiest part of the spec, since it's the least understood (by me)
23:35:32 <Travis> ... one other big thing:
23:35:47 <Travis> ... what we do with keypress vs textinput (and the char attribute)
23:36:01 <Travis> ... keypress is deprecated
23:36:19 <Travis> ... textinput was removed because HTML5 input event subsumed it's behavior.
23:36:25 <Travis> ... but it doesn't work quite the same way
23:36:40 <Travis> ... I think we need to add textinput back in. For folks currently using keypress
23:36:56 <Travis> ... additionally, if keypress is deprecated, then char attribute is useless
23:37:11 <Travis> ... if we don't have keypress then the char discussion are irrelevant.
23:37:24 <Travis> ... textinput event just gives you data (the string)
23:37:48 <Travis> The keydown/up events describe the char that will happen, no?
23:38:11 <Travis> garykac: Dead keys violate this assumption (can cause multiple keypresses)
23:38:21 <Travis> ... in the common case you can, but in general no you can't.
23:38:39 <garykac> There isn't a 1-1 correspondence between keydown/keyup and keypress
23:38:41 <masayuki> Travis: textinput event you said is fired *before* text editor's content is changed?
23:39:13 <Travis> garykac: What we have in the spec is that dead keys should be implemented as composition events!
23:39:20 <Travis> ... (I was surprised by this.)
23:39:25 <Travis> ... section 2.2.3
23:39:31 <garykac> 6.2.3 Dead keys
23:39:42 <garykac> http://www.w3.org/TR/DOM-Level-3-Events/#keys-DeadKeys
23:39:58 <Travis> masayuki: Yes, that is correct.
23:40:11 <garykac> YEs, the textinput can be canceled because it happens before the text field is updated
23:41:01 <masayuki> Okay, thank you.
23:41:18 <Travis> ... there was some weirdness in the examples (combining circumflex unicode instead of dead_acute)
23:41:39 <Travis> ... These examples need fixing
23:42:09 <Travis> Anyone else want to discuss a bug or bug category?
23:42:37 <Travis> garykac: keypress and char is my biggest open question.
23:42:52 <masayuki> me too.
23:43:11 <Travis> real_wez: DOM3 event seems to indicate that char is valid on keyup/down, but is not generally the case outside of latin characters
23:43:39 <Travis> garykac: you'd have to have JS implement a full IME just to figure it all out.
23:44:09 <Travis> real_wez: given that composition events have to indicate that character event has been generated...
23:44:34 <Travis> ... one option is to fold the composition event model into the textinput model
23:44:56 <Travis> garykac: What's nice is that you listen to one event. But with composition events, you have a begin/end pair.
23:45:26 <Travis> ... you end up with two events. Unless we allow the compositionend event existed without a start.
23:45:42 <Travis> ... I've heard folks don't want to fire more events than necessary.
23:45:47 <Travis> I agree too
23:47:00 <Travis> real_wez: We could drop char entirely if we have a separate event that contains the "char".
23:47:54 <Travis> ... with char on keydown/up, you can use that to see if those will generate character input or not; but in general, it's not reliable.
23:48:16 <masayuki> For i18n and better a11y of Web Apps, textinput approach is better since it doesn't depend on input device.
23:48:25 <Travis> ... composition events give that information via another route. So the key -> character mapping is not always clear.
23:48:48 <real_wez> You mean better than keypress+char?
23:48:59 <Travis> garykac: New question
23:49:01 <masayuki> real_wez: yes.
23:49:08 <real_wez> OK, I totally agree :)
23:49:38 <Travis> ... instead of using textinput, what about compositionend by itself?
23:50:06 <Travis> It doesn't semantically feel right...
23:50:21 <Travis> real_wez: Could adress this by a new compositiontext...
23:50:41 <masayuki> Travis: compositionstart and compositionend pair is important for some apps which want to stop its handler during composition.
23:50:47 <Travis> garykac: But pressing 'k' , it seems too complex for an entire composiion event sequence.
23:50:51 <garykac> The 'composition' part seems semantically wrong to me
23:51:16 <real_wez> Right; we wouldn't actually get rid of compositionstart
23:51:20 <Travis> So, we could confuse apps that expect a pair of events.
23:51:22 <Travis> garykac: So noted.
23:51:36 <real_wez> We'd just rename compositionend to compositiontext and then generate that stand-alone for simple input like Latin-1
23:51:44 <garykac> BTW, I'm not sure if I like the proposal - I just wanted to throw it out there to get opinions.
23:51:55 <real_wez> Yes, confusing apps that already understand composition could be an issue
23:52:01 <garykac> One thing I like about it is that it might encourage more apps to properly support composition events.
23:52:58 <masayuki> Hmm, renaming compositionend sounds risky. It might be used on some websites already.
23:53:25 <garykac> masayuki: agreed
23:53:40 <garykac> It's probably too late to consider at this point
23:54:05 <Travis> real_wez: If you're doing composed input (dead keys), you'd be generating more events (textintput, keypress, etc.)
23:54:29 <Travis> garykac: (looking back; textinput removed in 2012, added in 2003)
23:54:37 <masayuki> it might be better that textinput event is fired immediately before compositionend event.
23:54:53 <Travis> Would like to popup from bugs...
23:55:24 <Travis> What are the next steps and when should we reconvene to talk about progress
23:55:37 <Travis> garykac: Some of the bugs are editoral, some are naming discussions
23:55:42 <masayuki> Then, web apps can cancel the composition with the textinput event.
23:55:45 <Travis> ... others are bigger bugs which require more thought.
23:55:53 <Travis> ... discussion will probably happen in the bugs.
23:56:02 <Travis> ... I'd like to prune down the list (maybe 10)?
23:56:21 <Travis> I had proposed meeting every 2 weeks.
23:56:28 <Travis> garykac: Most concerned about locale stuff.
23:57:13 <Travis> Anyone we can enlist for locale help (BCP47)?
23:57:24 <Travis> garykac: I'm not sure I know anyone who's an expert there.
23:57:42 <Travis> real_wez: Boils down to what is locale for?
23:57:49 <Travis> garykac: We could remove locale.
23:58:00 <Travis> ... that complicates the UI Events getKeyCaps method.
23:58:05 <Travis> ... I haven't thought too much about that.
23:58:11 <Travis> ... who else wanted locale?
23:58:23 <Travis> ... anyone know what motivated it?
23:58:56 <Travis> Wondering if anyone would object to pulling it out of the spec?
23:59:22 <Travis> garykac: I can track that as a bug to file.
23:59:52 <Travis> garykac: How well did this telco time work for our friends from Japan?
23:59:59 <masayuki> I have no idea of a way to use .locale... So, I agree to drop it from the spec.