IRC log of webapps on 2013-05-07
Timestamps are in UTC.
- 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.