<Travis> hi folks!

<masayuki> Hello, Travis

<kochix> muted mine

<Travis> Gary present?

Hallo

<Travis> a?

lgtm

<Travis> More items to add to the agenda?

<masayuki> I'd like to discuss https://www.w3.org/Bugs/Public/show_bug.cgi?id=23908 today.

<Travis> Our co-chair has informed us that we can publish again in december up until the 7th.

<Travis> ... after that there is an end-of-year blackout for publishing stuff.

<Travis> ... If we want to get a LC out for our D3E spec, we must be ready to do so quickly.

<Travis> ... I see 19 bugs open in bugzilla for our component

<Travis> ... https://www.w3.org/Bugs/Public/buglist.cgi?component=DOM3%20Events&list_id=30204&product=WebAppsWG&resolution=---

Well...

I merged in all of the stuff from UI Events

So we have a first draft of all that.

Most of the remaining bugs seem minor (I think)

We should go through them to see which ones require discussion so that we can resolve them now.

I think we'd need to "sign off" by this Friday for this to be possible.

And

I would like it if people could review the sections that have changed

Namely: the keyboard layout section

and the updated initialization/constructor stuff

<Travis> I think if it's just the 4 of us that should agree that we'd be ready by friday, then we could probably all do a review in the next few days.

I'll be going though it again as well.

Because while I "wrote" it, a lot of the recent changes were merging the old text with the new text.

<Travis> masayuki: and kochix: what do you think?

I want to make sure that the text flows nicely.

and that there isn't anything obvious missing.

We'll probably need to start an email thread in order to track these issues this week.

<kochix> CompositionEvent looks good

<Travis> kochix: Believes what we have now is OK.

Updated section: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#keys

<Travis> Let's do a quick scan of the existing bugs. Perhaps we can knock out a few.

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

<Travis> garykac: I have notes on this...

<masayuki> I'm still reading the new ED carefully, and I'm filing issues on bugzilla.

<Travis> masayuki: excellent.

For 22073, we discussed this in Tokyo.

<masayuki> So, I'm still not sure if current ED is enough for LC.

<Travis> garykac: It would be nice to get this out in December, but there's always Jan.

<Travis> masayuki: Meaning there are still bugs to file, right?

It would be nice to resolve all the bugs before doing another LC.

<Travis> I agree.

I think that we're in good shape to hit early January.

<masayuki> Travis: I think so.

And I would feel more comfortable giving the text more time to be reviewed for typos and readability.

<Travis> Then perhaps we shouldn't be too agressive to finish this week.

sgtm

We should let Arthur know

<Travis> I can do that.

We should ask for the first available date in Jan.

<kochix> ah, one thing, please remove 2 references to 'inputmode' in beforeinput event.

There were only 2 references to inputmode?

<kochix> I think so,

<kochix> in 'beforeinput' and 'input' tables, 2 references of 'with inputmode set'

Refresh the ED - I've updated the spec to remove these.

<kochix> thanks

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

<Travis> garykac: <fixing easy bugs as we speak>

<Travis> ... 23912 fixed.

For the TV keys...

We may want to move those into UI Events (or some other doc)

We're going to try to make a stab at it, but it is really complex and we'll likely have to release a follow-up document as well.

But we can probably add a 'TV' key now, but getting all the other TV remote keys is not likely.

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

I've already updated to spec to add "If non-null"

ms2ger says that current implementations currently allow null and don't throw an exception.

So this is really documenting the current state of affairs with browsers.

<Travis> ms2ger's tests show that these apis always succeed (even if null is passed)

<Travis> ... where "these apis" mean addeventlistener and removeeventlistener

<Travis> garykac: is pushing a change out to address this now.

Fix for 23186 has been pushed.

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

<Travis> I closed it.

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

Travis is closing this bug because the events have changed a lot recently

<Travis> I resolved mine won't fix.

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

<kochix> ok, i'll revisit 23258.

<Travis> garykac: I will be fixing this, but haven't got to it yet.

I'll be fixing 23748 to refer to the table.

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

We discussed that (ScrollLock) in Tokyo and Nakano-san convinced me that it makes sense to add it as a modifier.

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

<Travis> masayuki: in comment 1, you refer to "example 30"

<Travis> ... is this from the spec?

Agreed that '' is the right answer since that's what gets inserted.

<Travis> garykac: I think it's example 34.

(and Example 30 is now Example 34 since 4 more examples got added earlier)

Things like DeadAcute + m should produce 2 chars: `m

I *believe* that's what we see on all platforms, but we need to check/verify.

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

<masayuki> This idea comes from XUL which is Mozilla internal API.

We should think about 23906 in the context of 22073 since they seem related.

<masayuki> I believe that if web apps want to implement their own shortcut key, this is useful.

If we have an accelKey, then do we want people to use osKey?

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

<masayuki> garykac: I don't think so. Even if web apps need to know the OS key state, there is getModifierState().

How do webapps determine now if a keydown generates text.

<Travis> Perhaps this is a feature that we can think more extensively about in UIEvents?

<Travis> ... does it need to go into DOM3?

<Travis> I'd like to move this to UIEvents. masayuki what do you think?

<masayuki> not necessary for D3E, it's okay it's in UIEvents.

It's an interesting problem...

23908 is an interesting case as well

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

<masayuki> I'm implementing KeyboardEvent.key for printable keys on Gecko, but bug 23908 blocks it on Mac.

<masayuki> So, I hope we decide the answer of this today.

<Travis> masayuki: what is your preference here?

<Travis> (On windows, I don't have a preference ;-)

We'll need to create some tests for this as well (since it sounds a bit bizarre).

<masayuki> Travis: I think that the modified key value, i.e., ASCII character is better. Even though the behavior is different from Ctrl key is pressed.

<masayuki> because the printable key's "function" is really changed by pressing command key press.

Dvorak switches from Dvorak -> QWERTY when the command key is pressed?

<masayuki> Especially, Dvorak-QWERTY keyboard layout users don't want web apps handles the key as Dvorak layout while pressing Command key.

But a French keyboard doesn't change the layout from AZERTY to QWERTY.

<masayuki> garykac: yes

<masayuki> shortcut keys of apps for English language users are designed for QWERTY. Therefore, Dvorak layout isn't useful for shortcut keys.

Is that just a weird behavior of Dvorak to deal with the fact that the keycaps don't match the layout.

<masayuki> Some Mac's Dvorak users like this special layout.

If the OS/keyboard-layout went through the trouble to do this, then it's probably nice to support it.

<masayuki> Non-ASCII keyboard layout such as Arabic keyboard layout also has same issue.

So an Arabic keyboard generates QWERTY values when the command key is pressed?

<masayuki> Pressing command key swtches the printable keyboard layout to QWERTY.

I've never tried that...

<masayuki> garykac: yes. You can confirm it with keyboard viewer of Mac OS X.

en-US? (not en-UK or anywhere else)

<masayuki> I think it's en-US.

<masayuki> IIRC, though.

According to Keyboard viewer...

cmd-a produces 'a'

cmd-shift-a produces 'a' (also lowercase)

for en-US

For Arabic

cmd-ش produces 'a'

cmd-shift-ش produces 'A' (uppercase)

This makes me sad

<masayuki> Oh...

My preference is for whatever the OS gives us easily.

I presume that the OS is doing things for a good reason.

And I'm not sure how to map this equivalent into Windows or Linux.

<masayuki> garykac: I don't think that Windows and Linux need to do same behavior since Command key is a special modifier of Mac OS.

<Travis> We should take a break.

<masayuki> Win/Super/Hyper shouldn't cause text input. So, the printable key values should be unmodified key value except Shift.

<Travis> When should we meet again?

<Travis> I won't be available in two weeks (or three weeks)

<Travis> I can meet again next week though it might be too soon?

Next week sounds good.

<masayuki> SGTM

<Travis> OK. Next week it will be.

That way we can get feedback

<Travis> We've made great progress on the bug list. Let's keep it up.

Hopefully everyone will have had time to go through the updates.

<Travis> Please file more bugs as we find issues.

<masayuki> Yeah.

<Travis> kochix: Looking into next draft of IME API.

<Travis> ... working with JianfengLi (Microsoft)

<Travis> ... hoping to close some bugs before dec. 7

<masayuki> garykac: Could you give your idea for bug 23908 in the bug if you're still thinking the answer?

<Travis> Last Call?

<Travis> Anything else for this meeting?

masayuki: for 23908 I don't have strong feelings either way. We should try using whatever the OS gives us easily. It doesn't sounds like it's worth adding a lot of special purpose code to handle that case.

kochix: Do you need anything else in the DOM3 spec for the IME spec work?

<masayuki> garykac: Thanks, then, I'll use the ASCII characters while command key is pressed.

Let me know if there's anything else.

<Travis> With that, I think we are adjurned.

masayuki: sgtm

<Travis> Bye everyone!

<Travis> See you next week.

good byte

oops

<masayuki> See you.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/he/we/
No ScribeNick specified.  Guessing ScribeNick: garykac
Inferring Scribes: garykac

WARNING: No "Topic:" lines found.

Present: Travis_Leithead garykac masayuki kochix

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 04 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/04-webapps-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report