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.