Pointer Events WG Voice Conference -- 07 Jan 2014

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

<jrossi2> * realized I don't have a mic .. brb

Tweak agenda

AB: Happy New Year everyone!
... I posted a draft agenda a few days ago http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0001.html.
... without Sangwhan present, perhaps we should postpone the "Compatibility Events" topic.
... any objections to that?

[ None ]

AB: any other change requests?

[ None ]

AB: anyone want to Scribe today's call?

RB: I'll do it

Scribe+ Rick

<scribe> ScribeNick: rbyers

Bug 21749 Setting a capture on an offshore element AB: Jacob filed 21749 on 19-Apr-2013; <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749>

AB: Originally based on input from Francois Remy

<ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0084.html -> Francois Remy

JR: Mail is longer than what I pasted into the bug
... It's possible this is an IE bug
... This is a good test case nonetheless - scenario requires some discussion
... Scenario: element not in the DOM - can you setCapture to that, let alone receive pointer events
... generally we avoid firing input events to elements that aren't in the DOM
... if you create an element (without putting it in the DOM) and call setPointerCapture, what should happen?
... Normally you'd only use setCapture on an element in the tree
... IE throws an exception but that's not written in the spec
... either could see fixing IE to make it not throw
... or update the spec to make it throw
... but open to discussion

RB: There's no scenario where an element not in the tree would receive a real input event, right?

JR: Right. Closest is an input sync - but could just be in the tree

AB: If there are no other comments, Jacob should propose spec change to the list

OP: Agree we should throw some exception. And for consistency if capture is on some element and then element is removed from the document, we should also release capture.

JR: Good point, we should capture that as well

DS: Trying to think of scenarios

SG: Scenarios where an element is removed and re-added elsewhere
... as far as the user is concerned it's just moving, not being removed
... not sure it needs to receive events while not in the tree, but should after it's re-inserted

RB: What does IE do when an element that has capture is removed from the DOM

JR: Just checking - believe it's released and get lostcapture event - good edge case we need to document

DS: Need to ensure event is rebased onto the right element

JR: Happens naturally as a result of hit-testing

RB: IE's behavior makes sense to me and ti seems quite edge-case since capture is always explicit (unlike touch events).
... Assuming IE hasn't got complaints, I think we should just spec what IE does here.

DS: Are there developers using pointer events extensively today?

JR: Yes - tons. Google maps, Bing maps, flipboard, all windows 8 apps, etc.
... we get lots of feedback from developers

DS: What I meant is is there someone we know using pointer events we could ask for their input?

RB: Did Francois express an opinion on whether IE's behavior was reasonable?

JR: Sounds like he's leaning towards IE behavior

DS: What about shadow DOM? Is that considered in the dom?

JR: Yes - just a different mechanism for how events propagate
... Test in IE shows that an element that has capture that is removed and re-added still receives events.

<ArtB> ACTION: Jacob propose text to address bug 21749; confirm change with Francois Remy [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-57 - Propose text to address bug 21749; confirm change with francois remy [on Jacob Rossi - due 2014-01-14].

RB: How about Jacob confirms IE's behavior here (eg. what happens to the events while the capture element is out of the DOM)

Bug 21951 - [CR] pointermove dispatching when button state changes;

<ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0134.html -> comment from Scott

<ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0141.html -> Jacob's reply to Scott

JR: Not clear in the spec that pointermove doesn't have to fire if the button change is captured by another event.
... Eg. putting the pointer down doesn't need to ALSO fire a pointermove.

SG: Right

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

JR: Looks like we already agreed to add a sentence

<ArtB> ACTION: Jacob propose text to address bug 21951 [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-58 - Propose text to address bug 21951 [on Jacob Rossi - due 2014-01-14].

RESOLUTION: Clarify pointermove does not fire for button change described by other events

Add non-normative example section to mouse compatibility event mapping? Raised by Rick and Patrick Lauke on 10-Dec-2013

http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0067.html

<ArtB> http://www.w3.org/TR/2013/CR-pointerevents-20130509/#compatibility-mapping-with-mouse-events -> Mouse Interop

Details: http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0068.html

JR: Yes, adding an example and some clarifying text sounds like it would address his concerns.
... would be relatively straight forward but helpful
... all included in the algorithm, but requires the reader to trace the algorithm
... would be helpful to have such examples

<ArtB> ACTION: Jacob propose text re "Add non-normative example section to mouse compat event mapping"; get confirmation from Patrick [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action03]

<trackbot> Created ACTION-59 - Propose text re "add non-normative example section to mouse compat event mapping"; get confirmation from patrick [on Jacob Rossi - due 2014-01-14].

DS: Agree - suggest Jacob proposes some text for this

"List of Pointer Events" table default actions; raised by Patrick Lauke on 10-Dec-2013;

http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0069.html

DS: Currently no replies on the list

JR: Yes I discussed this with him over Twitter
... confusion over word 'dispatch' isn't really the issue here
... The table reads as only pointerdown dispatches compatibility mouse events
... Not sure what the right wording is here

DS: Take discussion to the list or any other thoughts?

<ArtB> ACTION: Jacob reply to Patrick's "List of Pointer Events" ... thread [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action04]

<trackbot> Created ACTION-60 - Reply to patrick's "list of pointer events" ... thread [on Jacob Rossi - due 2014-01-14].

<ArtB> ACTION: Rick reply to Patrick's "List of Pointer Events" ... thread [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action05]

<trackbot> Created ACTION-61 - Reply to patrick's "list of pointer events" ... thread [on Rick Byers - due 2014-01-14].

DS: Will get Rick and Jacob to reply to patrick

Sub-pixel coordinate granularity; filed by Rick on 17-Dec-2013;

http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0074.html

RB: CSS px unit as an integer is increasingly lossly - eg. scrolling by CSS px on mobile devices is quite jumpy
... 1 CSS px is typically 2 or 3 hardware pixels on mobile devices

JR: Agree that any issues should be taken to CSS OM spec
... believe we already do this when user zoom is applied
... think we hit some website compatibility issues preventing doing this in all cases

AB: Any other feedback? Important topic but doesn't directly affect pointer event spec

JR: Yes I think the pointer event spec - doesn't assume co-ordinates are integers
... just a messy inter-spec dependency
... we link to DOM3 events spec, but that may not document relationship with CSS OM.

RB: Any harm in us having some text that refers to CSS OM?

JR: It's been a slow-moving spec - don't want to take a hard dependency on it

AB: If the text was non-normative it would be OK

JR: Yes, there's a normative reference to DOM3 mouse events, we could add a non-normative note that CSSOM extends it.

DS: Seems fine to me
... We could always change later - functionally the dependencies don't really matter in my opinion
... we should do most pragmatic thing for now
... can always change last minute

AB: So Jacob and Rick should propose text to address issue

RB: I think what Jacob just proposed is perfect

AB: Sounds find, any objections?

RESOLUTION: Add non-normative note that CSSOM extends mouse events

<ArtB> ACTION: jacob add a non-normative note that CSSOM extends mouse events [recorded in http://www.w3.org/2014/01/07-pointerevents-minutes.html#action06]

<trackbot> Created ACTION-62 - Add a non-normative note that cssom extends mouse events [on Jacob Rossi - due 2014-01-14].

Testing

Status of PR324 (touch-action tests)

AB: There were actions for Cathy and Rick to review

RB: I added comments back in Nov, but failed to send my summary notes to the list (found it tedious due to all the copy/past)
... sent those comments to the list this morning

CC: Agree with Rick. I reviewed them as well.
... but was very tedious

AB: Do we consider PR closed then?

JR: We've seen the feedback but haven't updated the test cases yet
... we should continue to iterate, and accept once everyone is happy

OP: Yes that makes it more clean

AB: So we'll get a notification from MS when comments are addressed

RB: I think someone (Scott) said they'd merge the tests

JR: We have a submissions branch - we'd want to accept the PR first, then let Scott do the refactoring

AB: Makes sense to me

RB: Yep, that's fine

JR: Otherwise we'll get into conflicts

SG: Makes sense to me

JR: Rick, can you help contributing your scenarios?
... lots of discussion about the architecture of the tests

<scott_gonzalez> I need to join another call.

Here's an exmaple of one of my blink tests: http://www.rbyers.net/touch-action-pan.html

Also if it's helpful, here are some others:

http://www.rbyers.net/touch-action-overflow.html

http://www.rbyers.net/touch-action-shadow-dom.html

http://www.rbyers.net/touch-action-simple.html

implementation status

AS: We're making progress on firefox, no specific update to report

<smaug> grr

<smaug> skype

<smaug> rbyers: do you implement also your proposed touch-action-delay property?

<smaug> and Zakim doesn't let me to re-call

RB: We've decided in chrome to ship touch-action support ahead of my proposed touch-action-delay.
... touch-action support is tracked here: https://code.google.com/p/chromium/issues/detail?id=241964 and over the holidays I got it essentially functionally complete
... so it's now available in Chrome canary builds by running with the --enable-experimental-web-platform-features flag
... there are some outstanding bugs / limitations with it, but the plan is to have those fixed in time to ship with Chrome 35 or sooner - i.e. on by default in daily builds by the end of March at the latest.
... Then we'll revisit the touch-action-delay vs. full pointer event debate

smaug: We're continuing major re-architecture to make touch-action-delay possible but don't have anything that is useful end-to-end yet

DS: How receptive is FireFox to pointer events work?

<smaug> rbyers: is it documented somewhere how touch-action and touchevents work together ?

AS: We're working with the community, will have more details next time

<smaug> in Chromium impl

smaug: With just touch-action (not touch-action-delay) there really isn't much interaction at all. Details are (burried) here: https://docs.google.com/a/chromium.org/document/d/1CV2AXyrdPdGSRypAQcfGrgQVuWYi50EzTmVsMLWgRPM/edit

<smaug> rbyers: but do you always dispatch touch events then?

<smaug> or only if there are listeners?

<smaug> touch-action is effectively opt-in

<mbrubeck_> hey guys -- sorry, I'm traveling and lost track of time zones

<mbrubeck_> looking for somewhere I can use a phone

<mbrubeck_> oh, looks like you are finished. oops

smaug: touch-ACTION: auto doesn't change behavior at all. Yes we always send touch events - the question is just when our 'touchcancel on scoll' behavior kicks in.

- DRAFT -

Pointer Events WG Voice Conference

07 Jan 2014

Attendees

Contents