<garykac> Working through the remaining issues on the ED: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html

Starting at the bottom...

scribe: mobile phone keys look like things we can skip.
... for pre-TPAC WD.

Current plan for issue 10 is to define as many as possible, then assign default indexes.

scribe: makes it extensible for the future.
... While launchapp1..n, it's not very well self-documenting.
... beyond launchapp1/2, GTK just seems to go with numbers

garykac: Thinking of defining the top logical ones and then the remainder for the future.
... issues 9 & 7 are the same relative to dead keys... skipping for now.
... Meta/Super
... we can leave these for now, and hash them out at TPAC.
... Mac/Windows key is supposed to be the same thing.
... need to resolve why we have an OS & Meta. Leave both in for now, and then resolve to remove the redundant one (whichever it is) later.
... Dead keys (I7-9)
... in example 29.
... keyup/down are supposed to be suppressed during the composition!
... May not be valuable to have enumerated dead keys because they won't even (generally) show up in the key flow.
... If implementations make dead keys work like composition bookends, then it's really about the data in the composition events, and supplying these dead key values is less important.

Travis: Need to update example 29 & 30.

garykac: We are expecting comments on the mechanism for handling dead keys with composition events. No implementations yet.
... masayuki was fine with getting rid of them.
... So, I will update this to drop the dead key values in the next draft.
... composition update order wrt dom updates (issues 6)

Travis: I suggest we hold issue 6 till after the TPAC update.

garykac: sounds good.

Travis: reviewed email with Kochi (http://lists.w3.org/Archives/Public/www-dom/2013OctDec/0012.html)

<garykac> Hi Masayuki. We're going backwards through the issues. We're now on issue 5.

<masayuki> sorry for the late.

Sounds like we have editor's agreement to remove locale from keyboard event.

scribe: that takes care of issue 5.

<garykac> moving on to issue 4

<garykac> We should move wheel mouse ticks into UI Events.

Travis: Feature request, we should punt it over to UI Events.

garykac: Agree.

<scribe> scribe: Travis

<garykac> With issue 3: generating click and dblclick for all mouse buttons...

<scribe> scribenick: Travis

<garykac> Reading the spec, there is a section that reveals the intent was to have these events fired for all mouse buttons.

UNKNOWN_SPEAKER: summary: you can't create pseudo double/triple clicks for any button if you only get the clicks for the left button.

<garykac> masayuki made the point last week that it is hard to simulate middle/right double click if it is not supported by the browser directly since the delay between the clicks is not exposed.

Travis: Given that Presto is largely out of the picture, it looks like the best intersection of browser behavior is to define this such that any button still fires click (not just the left button)

<garykac> so, the spec intent was to fire these events for all buttons.

Travis: I think we can all agree on that.

garykac: I will leave the text as-is then. (that's great)
... Mouse Event Order: should be normatively specified
... made a mouseevent test page
... IE seems to be the only browser that does enter/leave

[all] reviewing: https://dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html

IE/Firefox agree on the relative enter/leave/over/out

scribe: IE10/11 just throws in an extra mouse move!

<masayuki> Perhaps, the reason is, we emulate IE behavior if IE and WebKib/Blink behave different but both of them are not matter.

Travis: I will ask around and find out why we do this, to see if we should add a normative rationale for the extra mousemove.

<masayuki> I feel the "extra" mousemove is natural.

Travis: We should ask the Chair to issue the CfC for publication now.
... we can make the final edits as part of the publication process.
... (then we can have the spec ready for publication before the 28th deadline)

<masayuki> I think that native device event like mousemove should be fired first, then, its side-effect events (mouseout/leave/over/enter) should be fired.

<garykac> But the extra mousemove before the mouseenter seems odd. I expect the first event to be mouseover/mouseenter so that I can (for example) start recording mousemoves.

It does seem somewhat arbitrary, and I don't think it is--that's what I want to find out.

<garykac> I also expect mousemoves to no longer be sent after the mouseleave

<masayuki> garykac: Sounds your idea makes sense too. Hmm...

<garykac> But we can wait to see what the motivation was for IE. And update the spec as needed.

garykac: also thinking about re-publishing UI Events.

Shall we meet again on the 29th?

<garykac> Not sure if we need to. We should have a new spec out at that time.

<garykac> We can meet at TPAC (or post-TPAC for Masayuki)

We can tentatively have a meeting right after TPAC to review and take the next steps (Nov. 19th).

scribe: sound good?

<garykac> Any other issues before TPAC we can handle via email.

<garykac> sgtm

me too.

Ending early!!!

<garykac> see you all in a few weeks.

<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)

Found Scribe: Travis
Inferring ScribeNick: Travis
Found ScribeNick: Travis

WARNING: No "Topic:" lines found.

Default Present: garykac, [Microsoft]
Present: garykac [Microsoft] masayuki Travis

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

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