Re: DOM3Events telecon tomorrow (January 21st)

[17:05] == garykac [~garykac@public.cloak] has joined #webapps
[17:06] == kochi_home [~kochi_home@public.cloak] has joined #webapps
[17:06] <garykac> greetings kochi-san
[17:06] <kochi_home> morning
[17:06] <garykac> I'm the first one on the teleconf call.
[17:06] <masayuki> good morning.
[17:06] <kochi_home> hi Gary
[17:07] <kochi_home> good morning nakano-san
[17:08] <garykac> ohayou minna-san
[17:08] <masayuki> :-D
[17:10] <garykac> Travis is going to be embarrassed when he dials in and
discovers that everyone else got here before he did ^_^
[17:11] <garykac> We can start going through the bug list.
[17:11] <garykac> Frankly, I haven't looked at it since December, but I
need to start fixing the remaining bugs.
[17:11] <garykac> Are there any issues in particular that people want to
talk about?
[17:12] <masayuki> I worry about the key name or .key attribute is hard to
search in souce code https://www.w3.org/Bugs/Public/show_bug.cgi?id=23943
[17:13] <masayuki> Additionally, some .code values are same as .key values.
E.g., ScrollLock.
[17:14] <kochi_home> It's a bit away from the spec itself, but I'm
concerned about https://code.google.com/p/chromium/issues/detail?id=118639
[17:14] <kochi_home> > keydown and keyup events do not have proper keyCode
(it's always 0)
[17:14] <kochi_home> on Android
[17:14] <kochi_home> on Android Chrome.
[17:15] <kochi_home> Due to the Android input framework, sometimes it's
hard to assign a keycode (e.g. backspace) to KeyboardEvent.keyCode
[17:16] <garykac> Re: 23943, I think it's too late to change the name from
'key' to anything else since there are existing implementations. Although I
agree tha the name is unfortunate. Same with 'code'. Sadly the better names
like 'keyCode' were already taken.
[17:16] <kochi_home> People are complaining that the behavior is different
from desktop browsers and their web app doesn't work as expected on Android
[17:16] <garykac> As for the 'key' values, we did clean them up a bit and
added prefixes where they made sense.
[17:17] <garykac> You can't search for all the possible 'key' values since
they can be any Unicode string.
[17:17] == jsbell [~jsbell@public.cloak] has quit ["There's no place like
home..."]
[17:19] <garykac> Re: 118639: We're not addressing any of the 'keyCode'
problems.  This sounds like a Chrome-specific issue in any case. If Chrome
Android acted just like Chrome desktop, then (I think) people wouldn't be
complaining.
[17:19] <masayuki> kochi_home: Gecko always compute keyCode value from VK
rather than scan code, doesn't that help to fix the issue?
http://mxr.mozilla.org/mozilla-central/source/widget/android/nsWindow.cpp#1275
[17:21] <kochi_home> masayuki: see comment #102 of the issue above, from
"MSAOfficeWebApps", Firefox seems to behave the same (they can't get
keycodes for backspace either).
[17:21] == lmcliste_ [~lmclister@public.cloak] has joined #webapps
[17:21] <kochi_home> (interestingly, a Microsoft program manager is
reporting the issue in Chromium issue tracker :-) )
[17:22] <kochi_home> masayuki: thanks anyway, I'll look into Chrome code
later.
[17:24] <kochi_home> The problem of backspace is that, some IMEs don't send
key event, but they just remove surrounding text.
[17:24] <kochi_home> So we have to fabricate the backspace key event in
that case, if we would have to.
[17:24] <masayuki> Hmm, I'll check it later.
[17:25] <kochi_home> Unfortunately (?) Android webview has such an
emulation for backspace and developers looks confused that Chrome doesn't
work the same way.
[17:27] <masayuki> garykac: If we would add prefix for key names and code
values, it would be great. E.g., web apps can distinguish if a .key value
is a printable key's or function key's.
[17:27] <masayuki> garykac: And perhaps, it can prevent simple mistakes at
writing code which handles both .key and .code.
[17:27] <garykac> We did add a prefix for many of the 'code' values, (eg:
'KeyA' instead of 'A') to remove ambiguity.
[17:28] <garykac> I don't think we can add prefixes to 'key' at this point.
[17:28] <garykac> But I understand the concern about the 'key' and 'code'
values being the same (eg: for PrintScreen)
[17:28] == lmcliste_ [~lmclister@public.cloak] has quit [Ping timeout: 180
seconds]
[17:28] <garykac> However, I'm not sure that there's any real value in
giving them different values.
[17:29] <garykac> I tried to give the 'code' values different names
whenever I could.
[17:29] <garykac> Some were easy: (like key = ' ' vs. code = 'spacebar')
[17:30] <garykac> But for CapsLock and Tab and Delete and others, it seems
strange to have CapsLock and XxxCapsLock.  Would we then need to have
XxxSpacebar?
[17:30] <garykac> Things quickly got ugly.
[17:30] == lmcliste_ [~lmclister@public.cloak] has joined #webapps
[17:30] <masayuki> E.g., foo(event.key) and foo(event.code) could cause a
bug.
[17:31] <garykac> True.
[17:31] <garykac> But they should already for any of the common keys. (eg:
key = 'a' or 'A' vs code = 'KeyA')
[17:32] <garykac> It a relatively small set of keys with specific names
that share names between 'key' and 'code'
[17:33] <garykac> If anyone is checking for PrintScreen (or Tab, or
Delete), it probably doesn't matter if they use 'key' or 'code' since those
keys don't vary based on keyboard layout.
[17:33] <masayuki> Ah.
[17:34] <garykac> (But we should double-check that now that you mention it
- we definitely don't want to share names for any keys that change based on
layout).
[17:34] <garykac> If anyone is using 'code' when they should be using 'key'
to check for the 'a' key, they will quickly see that it doesn't work they
way they expected.
[17:36] <masayuki> garykac: In Example 24 of current ED, .code is empty for
keypress event. Is that intentionally?
[17:36] <garykac> I don't think so, but let me check.
[17:37] <masayuki> garykac: And there are no code values for the keys in
left side block of Sun keyboard.
[17:39] <masayuki> I'm not sure if they have specific USB Usage ID, though.
[17:39] <garykac> We should add the keys for the Sun keyboard. Does 23751
track all the keys that are missing?
[17:39] <garykac> I might remove the USB usageID - that's just for
reference anyway and I'm not sure how useful people find it.
[17:41] <garykac> re: Example 24. The keypress has an empty 'code' field
because it doesn't completely make sense for 'code' to be set since the
keypress event is the result of multiple keys (eg: shift + a).  We could
make it the value of the last key that contributed to the keypress event,
but that doesn't seem all that useful.
[17:42] <masayuki> Bug 23751 should care "legacy" keys :-)
[17:43] == heycam has changed nick to heycam|away
[17:43] <garykac> Which other ones do we need?  If you can add to that bug
or create a new one that would be great.  I don't have a Sun keyboard to
test :-(
[17:44] <garykac> We'd like to cover (almost) every key that can be typed
on a modern (or almost modern) keyboard.
[17:44] <masayuki> Okay, I'll file a bug for Sun keyboard with more
information.
[17:44] <garykac> The only keys I don't want to include are those that
cannot be typed on keyboards anymore (eg: old Lisp machine keyboards)
[17:44] <garykac> masayuki: thanks!
[17:45] <masayuki> Can I check USB usage ID of them? If it's possible, how?
[17:45] <garykac> masayuki: just a sec. I'll send a link to the USB doc...
[17:46] <masayuki> Windows hides the raw code with scan code...
[17:46] <garykac> http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf
[17:46] <garykac> Starting on page 53 is the Keyboard section.
[17:46] == lmcliste_ [~lmclister@public.cloak] has quit [""]
[17:47] <garykac> The keyboard is USB usage page 0x07, but some keys are
that found on newer keyboards (like Sleep) can be in the other Usage pages.
But we mostly care about 0x07.
[17:49] <masayuki> I don't understand how to check the actual code of a
key...
[17:50] <garykac> You mean something like hooking up a physical keyboard to
a device that will give you the USB code?  (because the host OS hides that
info)
[17:52] <garykac> I played around with getting an Arduino to read the raw
USB info from a keyboard, but didn't get it to work completely.
[17:52] <masayuki> Um, I want to check if the Sun specific keys share other
keys in typical keyboard layout or not.
[17:54] <masayuki> Ah, but it should be possieble with scan code of windows
or hardware_keycode of GDK, perhaps.
[17:55] <garykac> MSDN has:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645543(v=vs.85).aspx
[17:55] <garykac> RawInput mode, which sounds like it might give the raw
USB info.
[17:55] <masayuki> garykac: Oh, thank you. I'll check it.
[17:56] <garykac> Unless someone has created a translation table, reading
the raw data from the keyboard is the only way that I can think of.
[17:58] <garykac> I think that's all we have for today. We should probably
adjourn for now. Should we try meeting next week?  or two weeks from now?
[17:59] <masayuki> BTW, when browser cannot set .code value with unknown
key, .code should be empty string? or there is something special code value
like "Unidentified"?
[18:00] <masayuki> Either is okay to me (1 vs 2 weeks from now)
[18:01] <kochi_home> Travis sent a mail...
[18:02] <garykac> IIRC, the 'code' should be empty ('') in that case.  We
should mention that explicitly in the spec, however.
[18:03] <masayuki> garykac: thanks.
[18:04] <garykac> OK. So let's try for next week. I'll hopefully have
knocked out a few of the bugs and we can discuss matters from there.
[18:04] <garykac> Thanks.
[18:04] <kochi_home> Thanks
[18:04] <garykac> I'll send a copy of this chatlog to the mailing list.
[18:04] <masayuki> Okay, thank you.






On Tue, Jan 21, 2014 at 5:58 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  Yeah, so I was late for this again. (Yes, I’m feeling very guilty…)
> Hopefully I was the only one that missed this… Anyone want to send notes?
>
>
>
> *From:* Travis Leithead
> *Sent:* Monday, January 20, 2014 10:36 AM
> *To:* 'garykac@google.com'; 'wez@google.com'; 'olli@pettay.fi'; '
> karlt@mozbugz.karlt.net'; 'masayuki@d-toybox.com'; 'kochi@google.com'; '
> www-dom@w3.org'; 'hsteen@mozilla.com'
> *Subject:* DOM3Events telecon tomorrow (January 21st)
>
>
>
> We’re trying again to successfully get together after the new year!
>
>
>
> We will be meeting for our DOM L3 Events call tomorrow (January 21st). If
> you’d like to suggest specific agenda items, please reply or add them
> directly to the Wiki page: http://www.w3.org/2008/webapps/wiki/DOM3Events
>
>
>
> Here are the call-in details for tomorrow:
>
>    - IRC: Please login to #webapps (irc://irc.w3.org/) as you participate
>    on the call, so that we can create an easy-to-read and accurate log for
>    those folks not on the call.
>    - Phone Bridge: W3C's Zakim Bridge +1.617.761.6200; PIN = 3663#
>    ("DOM3"); SIP information <http://www.w3.org/2006/tools/wiki/Zakim-SIP>
>    - Time and Day of Week:
>       - San Francisco: 17:00 Tuesday
>       - Boston: 20:00 Tuesday
>       - UTC: 00:00 Wednesday
>       - Paris: 02:00 Wednesday
>       - Helsinki: 03:00 Wednesday
>       - Tokyo: 10:00 Wednesday
>    - Duration = 60 minutes maximum
>
>
>
>
>
>
>