W3C

- DRAFT -

DOM Events

11 Feb 2015

See also: IRC log

Attendees

Present
Travis, Gary, Masayuki
Regrets
Chair
Travis
Scribe
Travis

Contents


masayuki: Hi!

<scribe> Scribe: Travis

<scribe> ScribeNick: Travis

Any topics for today?

<masayuki> I'm trouble in bug 27991 and bug 27990

<masayuki> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27991

<masayuki> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27990

We can look at those.

Any other topics?

I've been working on a fix for 26019 :-)

Should have it checked in tomorrow.

<masayuki> Travis: Sounds great!

Gary is getting his head in the game.

(Still sore at the recent Seahawks loss, I'm sure.)

<masayuki> Ah, I have a news. Gecko will support .code in release build starting 38.

<garykac> Yay!

Great!

<garykac> I realize that I need to update the specs for the rename -> UIEvents and then ping "the powers that be" to have them redirect the short URLs as appropriate

<masayuki> (38 will ship May, 2015)

<garykac> We're working on getting 'code' exposed as well. I don't recall the release schedule, though.

OK.

Gary and I have some updates to finish from last telco which we should be able to do this week.

Let's take a look at those bugs masayuki reference earlier.

Bug 27991

<garykac> For 27991

<garykac> I *think* that Numpad makes more sense (because of the arrangement of the keys)

<garykac> But NumLock is not present, so I don't think that hacking NumLock to be true makes sense

<masayuki> Okay, so, if they input [0-9], NumLock should be hacked, otherwise, shouldn't be hacked?

<garykac> For 27990, my initial thought is NumpadAsterisk and NumpadHash

<garykac> masayuki: I don't think we should set NumLock at all for these keys.

I commented in the bug--I suggested Digit for the horizontal layout.

scribe: I'd expect more common code would look for digits, rather than numpad keys.

<masayuki> Wow, is there horizontal layout?

<garykac> The 'Digit*' keys are the one that have punct in their shifted state (US layout). They do not produce digits for some other layouts (like French), so the Digit codes don't seem appropriate for the phone numpad keys.

<garykac> masayuki: horizontal as opposed to in a 2d grid

<garykac> masayuki: 1d (horizontal row) vs. 2d (3x4 grid)

<masayuki> garykac: Thanks, I've never seen 1d in Japan.

<masayuki> I still have no idea which is better... (Numpad* vs. Digit*)

<garykac> I'm adding a comment to the bug.

<garykac> I don't think that Digit is appropriate for Phone keypads.

I think it's mostly arbitrary, but we should recommend one or the other. Digit works for me.

scribe: but I could go with either.
... but not both :-)

If we do Numpad*, then bug 27990 is easier to resolve.

scribe: code of Digit3 doesn't conflict with code of NumpadHash
... or we could have the numbers be Numpad*, and just reuse Digit3 for the code of #.

<masayuki> I think there are two scenarios one is some developers use scancode which is used by PC keyboard, the other is some developers use scancode which is NOT used by PC keyboard.

<garykac> masayuki: Phone keypads in the US have '#' and '*', but is that universal?

<masayuki> For the former, Digit3 and Digit8 may make sense. For the latter, NumpadHash and NumpadAsterisk may be good values.

<masayuki> gacykac: I'm not sure, but Japanese phones have them and in some countries, they are.

<masayuki> https://www.google.co.jp/search?q=phone%201d%20layout&oe=utf-8&gws_rd=cr&um=1&ie=UTF-8&hl=ja&tbm=isch&source=og&sa=N&tab=wi&ei=Wq_aVJHJM5fz8gXAwIHgAg#um=1&hl=ja&tbm=isch&q=featurephone+buttons&imgdii=_

Bug 27990

<garykac> I think that NumpadAsterisk and Hash make the most sense for phones in all cases. If you hook up your phone to a PC, I would still expect to see the Numpad values.

<garykac> Digit3 and Digit8 just happen to match (shifted) the # and *, but that's only for the US locale and that seems very arbitrary.

<masayuki> garykac: yeah, but there might be no unused scancode.

<garykac> masayuki: thanks for the link. The '#' and '*' keys seem pretty universal.

<garykac> masayuki: unused scancode? why does that matter?

<masayuki> garykac: If so, vendors might map scancode which are used by PC keyboard. Then, browsers cannot distinguish the key event comes from the keys on feature phone or connected PC keyboard.

<masayuki> Ah, but it could be solved with virtual keycode values if the platform has specific keycode values for them.

<masayuki> Anyway, I'd like you to add featurephone section into D3E KeyboardEvent code spec.

<garykac> masayuki: we could expand the "Numpad" section to include a feature phone keypad. Since the other keypad values are there, it seems like a good place for that info to live.

<garykac> masayuki: File a bug for me to add a section for that.

<masayuki> garykac: Okay!

<garykac> That's probably about it for today...

Anything else to go over?

<masayuki> Nothing.

<garykac> See you all in two weeks.

Awesome. Two weeks!

<garykac> I hope to have the renaming in place by then.

<garykac> And the phone keys shouldn't take long to add.

<garykac> Bye!

<masayuki> Thanks!

RRSAgent: make logs public

<masayuki> garykac: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27996

<artb> Meeting: DOM and UI Events

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/02/11 12:54:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.99)

Succeeded: s/Numpad/NumLock/
Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis
Default Present: [Microsoft], +1.425.893.aaaa
Present: Travis Gary Masayuki
Got date from IRC log name: 11 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/11-webapps-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]