<garykac> I am here

<garykac> .

<masayuki> I'm here.

I think this is the current draft: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

Let's get started!

<garykac> Shall we start going through the spec?

garykac: All issues should be reflected in the doc.

<garykac> Skipping over Issue 2 (spec mouse event order)

Search the doc for "issue " :-)

<garykac> Issue 3...

<garykac> should right/middle button generate dblclick

No consistency between browsers on the issue currently. The bug is to request the old Presto (Opera) behavior.

It sounds like the recommended approach is the least compat-risky.

<masayuki> I like firing click event for any buttons.

<garykac> It will be hard to be consistent across browsers...

<garykac> Not firing the events seems like the safest approach...

The effect of making this change would be to say "there is a 'primary' mouse button, and it's action is to fire click events--any other button would not do that".

This is a fairly straightforward story to tell.

<masayuki> If there is no click event, web app develpers need to handle both mousedown and mouseup.

<garykac> The alternative is that *all* buttons need to generate these events. And if we have a device with 15 buttons, they would all need to generate these events.

The notion of a "primary" mouse button is not new to the spec, so could be easily leveraged here.

<masayuki> If there is no dblclick event, they need to hande the events while a specific time but they don't know the good term for dblclick.

<garykac> Clickcount is supposed to do that.

I propose that we pick a direction and commit it to the spec (even if it's wrong)

<garykac> (but it may not be consistent)

<masayuki> I agree with "*all* buttons need to generate these events".

masayuki: See the argument in the bug: The problem with Blink/WebKit's approach is that sites do something on click which doesn't make sense to do if the user clicks the link with the middle mouse button which should open the link in a new tab. Both actions happen which is not what the user expects.

Browsers are playing tricks to mitigate the problem.

I'm generally supportive of moving the click action to the primary button only.

Mouse down/up's are still fully functional.

<masayuki> Travis: I think that it's site specific problem. Are there too many such sites?

Well, it's the user-interaction problem, not a site problem.

I (the user) want to middle-click to open in a new tab.

<masayuki> I think that middle click event should be available on web apps but if they handle it, they should call preventDefault(). And then, browsers shouldn't open new tab.

OK, let's take this discussion to the bug--masayuki, I think you make a good argument, we should continue this conversation there for full exposure.

Let's move along.

<garykac> Issue 4

garykac: ...was looking at a newer version... back on track now.

I'm not sure what locale is trying to accomplish; is it keyboard layout? Is it language?

It's pretty ambiguous [sometimes], e.g., US-international.

<masayuki> I think it's OS's keyboard layout, not physical keyboard layout.

How might EN-US international layout be expressed with BCP 47?

<garykac> The issue with locale is that the CompositionEvent uses is as well. If we remove it from the KeyboardEvent, we'll still have a locale_ in the IME events.

<masayuki> I created an experimental patch for Gecko, but I cannot implement consistency behavior across platforms...

<masayuki> garykac: I think that we should drop it from both KeyboardEvent and CompositionEvent in D3E.

<masayuki> I believe that we need better idea for computing the value.

I agree

<garykac> The best it could do is report the OS layout - but it will usually match the physical keyboard

<garykac> masayuki: agreed

<garykac> I'm concerned that the IME events may need it though

In Win8 Language and Keyboard layout are fairly independent.

<garykac> So, it sounds like we should move locale into UI Events

<masayuki> garykac: what's case do you concerned with IME?

<garykac> I recall hearing that locale was used to help identify which IME language

<garykac> I don't have an example of where it would be necessary, however.

I do think being able to detect the lanaguage is key for IME scenarios. Locale as the keyboard layout may not have been accurate, but was loosely sufficient.

<garykac> IIRC, it was useful for distinguishing between Japanese, Chinese, et al.

I would certainly want the IME API spec to pick up something to fill the gap, if we chose to remove locale from D3E.

<kochi_home> Sure, I'll add it to my TODO.

Let's try to make progress on the bug. I think if we can coordinate with IME API that might be great.

No action on issue 4 yet.

<kochi_home> issue 5

<masayuki> Gecko doesn't dispatch any key events during composition, but we *can* change the behavior. (need a lot of time, though).

Issue 5 is apparently resolved

Related to issue 5: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23258

Chatted with folks who did the IME API work in IE11--they do all their IME adjustments in the compositionupdate event, and wanted the DOM to be current when the event was fired.

(It is current today.)

There is no commentary on bug 23258, so I don't know how anyone else thinks about this.

<garykac> I need to review the spec to make sure it's consistent with what we decided during the last call.

Gary did notice some inconsistencies in the spec with the written order.

<garykac> Then I'll compare that with the new bug Travis links above and make sure there are no new issues.

Any other feedback on issue 6?

<masayuki> Are there useful case for catching the composition updating before actually DOM is changed?

<masayuki> If it's necessary for some developers, making compositionupdate and compositionupdated events may be good solution.

<garykac> masayuki: Perhaps trying to cancel before the DOM is updated?

<kochi_home> masayuki: can beforeinput be used for catching event before DOM is updated?

<masayuki> kochi_home: If it's true, isn't input event enough for catching DOM change?

<kochi_home> maybe, so compositionupdate event is for getting the composition text itself, not the whole value in the field?

<garykac> beforeinput and input serve that purpose for most developers.

If the compositionupdate event _included_ all the relevant IME info, then I think this is a moot point.

<masayuki> kochi_home: yes

<garykac> the composition events don't need to wrap the DOM update - it would be nice to place it consistently before (or after - whatever we agreed on last time ^_^)

The web dev would just have to know that they shouldn't read the DOM during composition (if it happens before)--they'll always be getting stale input.

<garykac> but beforeinput and input should handle the "i need to know before the update" and "i need to know after the update" cases

I think that we have all the right notifications for input changes before and after.

Moving to issue 7

<garykac> For issue 7, just file a bug if there are any other examples that should be included

Might be nice to callout the scenarios enabled by UIEvent's 'code' property, lest there be any compaining at CR time.

Let's stop here for today.

TPAC planning

<garykac> I've been waffling...

<garykac> I haven't made arrangements yet, but I'm still considering.

I will be attending all week.

<kochi_home> i'll be there

<garykac> If I go, I'd be stopping in Tokyo afterwards.

<kochi_home> garykac: nice!

Do we want to plan on achieving any specific milestone for the event?

E.g., getting a new WD published?

Or event pushing for CR?

<garykac> We should certainly try for that.

garykac: New issue count has dropped...
... and we're making pretty good progress.
... many of the issues are "fluffy" (can be resolved easily).

We're roughly 5 weeks from TPAC

Historically there's been a publishing blackout for 2-3 weeks prior to the event.

That leaves us with about 2 weeks to prepare for re-publishing.

I propose we meet again next week to keep our momentum going...

Can folks make another telco/IRC chat on the 8th?

<garykac> Masayuki: Do you ever head into Tokyo? It would be nice to meet in person after TPAC if possible. I might be in Tokyo that Friday (15 Nov), but I'm still working out arrangements.

<masayuki> garykac: perhaps, I can go Tokyo.

<kochi_home> masayuki: nice!

Let's meet again next week then.

<masayuki> But, 17 Nov, I have a plan in Osaka/Kyoto. So, I need to be back at least 16 Nov.

<kochi_home> in that case, I'll be at TPAC Mon-Wed, go back to Tokyo on Thu, then meet Gary and Masayuki on Fri.

<kochi_home> (tentative plan)

<garykac> OK. I'll keep you posted with my travel arrangements. Hopefully, it will all work out.

garykac: Feel free to kick off specific mails to move issues along on the public list. Might help move things along faster.

<garykac> thank you everyone.

Thanks everyon!

<kochi_home> thanks!

<masayuki> Thanks!

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/didn't/did/
No ScribeNick specified.  Guessing ScribeNick: Travis
Inferring Scribes: Travis
Present: Travis garykac kochi_home

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: 02 Oct 2013
Guessing minutes URL: http://www.w3.org/2013/10/02-webapps-minutes.html
People with action items: 

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