Pointer Events WG Voice Conference -- 19 Nov 2013

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Tweak agenda

AB: any change requests for the proposed agenda http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0056.html?
... Since Sangwhan sent regrets, perhaps we should not cover the "Compatibility Events" topic and defer discussion to the list or add it to the next call if there is no "conclusion" on the list.
... any objections to dropping Compatibility Events?

[ none ]

AB: ok, we'll drop that and please followup on the list
... any other change requests?

JR: bug 22891 was from Sangwhan

… perhaps we should drop that too

RB: agree

AB: any objections to JR's proposal?

[ none ]

How should touch-action apply to multiple fingers?

AB: Rick raised this question on November 6 http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0050.html

RB: I was initially assuming this was out of scope

… but since panning is potentially more than one finger

… then I think we should talk about how that works with touch-action

… Spec seems to assume touch-action will only have one touch point

… need to think about multiple touch points too

… Would like to understand IE's behaviour

JR: for IE, behavior depends on other gestures

… if add pinch/zoom, can support multiple fingers

… f.ex. if panning

… don't think of panning and zooming as separate gestures

… whether or not there are multiple fingers is an artifact

… Not sure how to be more specific for action model

… Tried to be gesture-agnostic

RB: what about touch-action auto and none

… if have auto on a and none on b

… and then touch both a and be elements

scribe: .what is done

JR: in Rick's case, depends on which gestures the UA supports

… the gestures that are triggered depend on the UA

RB: what if 1 finger is pan x

… and another finger is pan y

… saying only panning is allowed

JR: so want to say only pan x

RB: if browser implements nothing more than what we supply

… can the UA just support what the spec states

JR: not sure how to do that without compromising other things in the spec

… could have diff combos of fingers

RB: re scope, could say t-a model looks at all possible intersection and says that's the way it works

<rbyers> Would it be in scope, for example, if we wanted to say that the touch-action processing model was as follows:

<rbyers> look at the touch-action under each active touch point and use the intersection to determine what action is permitted

<rbyers> i.e. we're not really comparing pointers at all, just using multiple touch-action values

JR: I think we could describe something like that

… but not sure if it solves the fundamental problem

… of not understanding IE's behavior

… If have one element that has a rule to pan-x

… now if have 2 fingers

… is pan in x direction allowed

… for some browsers, 2 finger pan-x works

RB: I think we'll have different behavior for same gestures

… for the purposes of this group, are we saying that anything with more than 1 finger is out of scope?

JR: if I take a broad understanding of the group's scope, then yes, I agree

<jrossi> http://www.w3.org/2012/pointerevents/charter/

… (anything beyond one finger is out of scope)

<jrossi> "Gestures. Examples of out-of-scope gesture functionality and APIs include, but are not limited to, the following: Comparisons between pointers to determine an action (e.g., panning for scrollable regions, pinch for zooming, press-and-hold for a mouse right-click)."

RB: ok, I can understand that

… I do need to think more about what this means

… f.ex. need to gather some data

JR: think most content will be for auto

… think we'll get good interop without being more specific

… The more advanced cases will require a broader scope

RB: pinch is a common scenario

… everyone will need to do it

AB: yes, we do need to consider the scope (and there could be some IP concerns)

touch-action hit testing

AB: Rick started this thread on November 14 http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0055.html

RB: the algorithm as written today is misleading

… t-a proc model needs to be more specific

… especially as hit testing is related to CSS

JR: there is no spec that defines hit testing

… thus the general definition

… There have been some efforts to define it

RB: CSS Object Model touches on this

JR: but that just defines the IDL

RB: without defining how it works, can we say @@

JR: think we can add some text about block elements

RB: yes, think we need some clarifications re block elements

JR: think that can be done as an informative note

RB: that would be fine with me

… need to define "touched element" or at least clarify it

… f.ex. has the following properties ...

… Don't want surprises

JR: agree need some clarifications

… and eventually define 'hit testing'

<AutomatedTester> ArtB: I raised https://www.w3.org/Bugs/Public/show_bug.cgi?id=23825 re hit testing in CSSOM

RB: I can propose some text

JR: I can propose some text via the list

RB: some of testing led to this topic getting released

AB: RESOLUTION: multi-finger: we will not define additional behavior for multiple fingers because of scope concerns
... any objections?

RESOLUTION: multi-finger: we will not define additional behavior for multiple fingers because of scope concerns

AB: RESOLUTION: hit testing: Jacob will draft proposed Note to clarify details of hit testing is out of scope, we will clarify properties UA's must adhere to for hit testing

RB: change "we" to "and"

RESOLUTION: hit testing: Jacob will draft proposed Note to clarify details of hit testing is out of scope, and we will clarify properties UA's must adhere to for hit testing

Bug 22890

AB: bug 22890 was filed by Olli on Augus6 6 "It is not clear why navigator.pointerEnabled is needed" https://www.w3.org/Bugs/Public/show_bug.cgi?id=22890

JR: we talked about this issue before

… not necessary from a technical view

… concerned about removing this for compat reasons

… If we want to mark this "At Risk", we would have to go back to LC->CR

… we wouldn't remove it from our impl

… at least not initially

… we could remove it from our docs

… A question is what the group wants to do about it

… I think this would be the only substantive change to the spec

RB: if we were going to make this change, then we should consider other substantive changes like hit testing

JR: I think the hit testing change could be done with out a substantive normative change

… but the new text would need to be testable

RB: I don't have a strong opinion

… if left in the spec and FF and Blink don't implement it, what are consequences

… If no one else implements it, we can't get out of CR

JR: I'm comfortable with making this change

… if we need to go back to LC/CR, we could try to scope the review to just changes since the last LC/CR

… that helps preventing a bunch of new comments

RB: makes sense

<rbyers> sorry, trying to address the noise

AB: if we make any substantive changes, we will need to go back to LC/CR

… my recommendation is to first complete the test suite and get 2 impls before going to LC/CR

AB: another option is to get the Impl Report done before LC#2

… and then we can skip CR and go right to Proposed Recommendation after the 3-week LC review period is complete

AV: what is the minimum LC review period?

AB: 3 weeks
... do we have a resolution for bug 22890 that we want to fix this bug?

RB: yes, I think we need to do this to get 2 impls to pass the tests

AV: yeah, I agree

RB: if we remove it, think we will get to REC faster

AV: yes, I think that is true

<rbyers> note that the impls may still someday add this API for compat with IE, but only if substantial compat testing showed it was necessary - so if we wanted to count on that it would probably delay getting to REC...

… think we should focus on Testing and Impl and the process steps will then follow

AB: RESOLUTION: agree that navigator.pointerEnable should be removed from the spec
... any objections?

[ None ]

RESOLUTION: agree that navigator.pointerEnable should be removed from the spec

Status of PR324 updates

AB: what's the status of processing PR324 comments? https://github.com/w3c/web-platform-tests/pull/324

AV: we are reviewing comments

… I don't have a ETA

… but we are working on them

RB: if you want to give me feedback on my comments, please let me know

… not clear how much value there is for comments during the test case review

AV: if we have any issues, we'll let you know

… comments are always welcome

Need touch-action tests

AB: since the draft agenda was posted, Jacob announced Microsoft added some touch-action tests to PR324 http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0059.html. The new commit is https://github.com/InternetExplorer/web-platform-tests/commit/886568a445cded3b5aa01f0c8befb48e0534fed6
... it appears there are several new tests

… this is excellent

RB: yes, this is good

AV: you should be able to use them Rick

… if you have feedback, please let me know

RB: I can review them

AB: if anyone else wants to review them, that would be great

CC: I'll review them

AB: great

RB: as I'm working on our impl of touch-action, I will do testing

… would like to share them with the group

… but probably need to keep the blink tests separated

AV: I'll assign actions to Rick and Cathy

<scribe> ACTION: Rick review touch-action tests [recorded in http://www.w3.org/2013/11/19-pointerevents-minutes.html#action01]

<trackbot> Created ACTION-54 - Review touch-action tests [on Rick Byers - due 2013-11-26].

<scribe> ACTION: Cathy review touch-action tests [recorded in http://www.w3.org/2013/11/19-pointerevents-minutes.html#action02]

<trackbot> Created ACTION-55 - Review touch-action tests [on Cathy Chan - due 2013-11-26].

Gaps in coverage

AB: we still have some gaps in http://www.w3.org/wiki/PointerEvents/TestAssertions

<rbyers> eg. if anyone is curious, here's a simple touch-action test case I'm landing in blink: www.rbyers.net/touch-action-simple.html

AV: not sure if Jacob update the wiki yet

<scribe> ACTION: Jacob update the TestAssertion wiki re touch-action tests [recorded in http://www.w3.org/2013/11/19-pointerevents-minutes.html#action03]

<trackbot> Created ACTION-56 - Update the testassertion wiki re touch-action tests [on Jacob Rossi - due 2013-11-26].

AV: there are 17 test assertions without tests

… we are working on them

… some time soon expect to contribute our tests

… We have 3-4 that need some discussions

AB: ok, that sounds great

… are some assertions not clear?

AV: for some, it's not clear how to test the assertion

AB: please do followup on the list

CR implementation updates

AB: any new progress on implementations?

RB: I've been making progress on touch-action

<rbyers> Implement simple touch-action support in blinki on the main thread: https://code.google.com/p/chromium/issues/detail?id=316735

… Driving for basic touch-action impl behind a flag by mid-December

… this work uncovered some design issues

AB: IE11 is now available on Win 7 and up?

AV: yes

… re FireFox, we reported a while ago about a FF patch

… Rick has been part of the discussion thread

… I don't have a firm ETA

… other than there is some progress

AoB

AB: are there any other topics for today?

AV: when will we meet again?

AB: good Q

… I'll ping Sangwhan

AV: we need to make progress on the test suite

AB: I agree

… we may have next week, depending on topics and availability

AV: Rick is out next week and me too

AB: no meeting on Nov 26

… so next potential meeting is Dec 3

AB: meeting adjourned

- DRAFT -

Pointer Events WG Voice Conference

19 Nov 2013

Attendees

Contents