See also: IRC log
<ArtB> Scribe: Doug
<ArtB> ScribeNick: shepazu
<rbyers_> I can scribe, but will want to hand off to someone else if we get deep into discussion blink, touch-action etc...
<smaug> I think
<rbyers> scribe: rbyers
<scribe> scribeNick: rbyers
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0007.html
OP: Touch-action and touch-events
is the TestAssertion data up-to-date; where are the holes? Who can commit to create tests to fill the holes (and by when)? <https://www.w3.org/wiki/PointerEvents/TestAssertions>
AB: Jacob, Matt, Cathy - any idea
what coverage we have?
... and is the data we have here accurate and up-to-date?
Asir: I don't know if it's fully up-to-date, but I can take an action to ensure there's a link for each assertion from the wiki to test case
AB: That would be excellent
Asir: 66 in the wiki, the recent
PR covers 54, leaving 12. Jacob has been pushing some changes
to cover 2-3.
... Scott has the remaining ones, has an action to create PRs
for them
... Scott's should cover about 9 of the remaining ones
SG: TWF submission covers 3.1,
3.2, 12.1, and some additional ones not listed on the
wiki
... 12.1 is covered in Microsoft's submission PR1074, so I
won't merge mine in - just verify we have the coverage
... for the others we should create new test assertions on the
wiki, right?
Asir: how many do we need to create?
SG: Not sure. Tests for
gotpointercapture/lostpointercapture firing async.
... and more extensive pointerleave tests with deeply nested
elements, but not sure the complexity is necessary
<scott_gonzalez> https://github.com/dmethvin/pointerevents-test/blob/master/pointerenterleave-continuous.html
SG: see diagrams on line 175
RB: some nested element case for enter/leave would be good to test - an easy thing to break
SG: So I can add assertions to the wiki and put together a PR for whatever doesn't overlap
<scott_gonzalez> https://github.com/dmethvin/pointerevents-test/blob/master/pointerenterleave-continuous.html#L175
SG: I can try to get this done for next week
AB: Next call will likely be next tuesday in August unless someone else wants to chair
DS: I would probably be available to chair
AB: Ok, let Doug know if you want to have a meeting next week
AV: Implementations are blocked
on testing, so any help to get tests landed quickly would be
helpful
... let us know if anyone needs help
AB: Scott let us know if you need
help getting this done for next week
... Anything else on this topic?
... Also covered the next: Test Assertion cleanup: if a TA is
covered by a merged tests, the data in "Test Status" column
should be a link to the merged/approved test case <http://w3c-test.org/pointerevents>.
Who can commit to helping with this?
<mbrubeck> https://github.com/w3c/web-platform-tests/pull/1074
AV: If there are no comments we should merge
CC: I had some questions in github
JR: There were two questions. 1)
is it true that IE fails some of the tests (constructor test
and pointerleave after pointercancel test). Yes, we're looking
at what we need to do. Tests are correct.
... 2) a minor thing - title element on constructor test should
go on head. If Artim hasn't corrected then I will.
CC: Also one with an incomplete
assertion
... a quick fix, but needs to be fixed
AV: Can we make those quick fixes and merge it in?
JR: Cathy do you agree it's fairly obvious what needs to happen to address these? Or do you want to review?
CC: They're trivial, fine to fix and land
SG: Also one for script changes to be relative
AB: Sounds like we have agreement on what needs to change. Jacob can merge once those fixes land.
<jrossi> ACTION: jrossi to make final corrections and merge PR 1074 [recorded in http://www.w3.org/2014/07/15-pointerevents-minutes.html#action01]
<trackbot> Created ACTION-114 - Make final corrections and merge pr 1074 [on Jacob Rossi - due 2014-07-22].
AV: I believe we have one or two
more PRs coming in to plug remaining holes
... it would be great if we could get these in within a weeks
timeframe - would really help implementers
AB: Anything else on testing for today?
AB: Main open question is Firefox metro - is that 100% implemented now?
MB: It's very close, out of 72 test cases (including merged and submmitted) it's passing all but 1.
<mbrubeck> https://bugzilla.mozilla.org/show_bug.cgi?id=1036985
MB: 1 is a recent regression we're actively working on fixing.
OP: And there's a bug open to handle the legacy mouse events properly
AB: Anybody have anything else
about the FF implementation?
... Any other new news regarding CR implementation?
<scribe> scribenick: mbrubeck
OP: the amount of new spec
required is rather small
... it's mainly about what events are required and when
RB: We talked about this when we
were first landing touch-action in Blink
... including whether touch-action should be in its own
spec.
... We talked about two things: The effect touch-action has on
actions in the browser, and the effect on events.
... Aside from the stuff directly around events (like
pointercancel), everything else is about browser actions.
... In terms of what happens to the events, there's no change.
Blink has made some changes, but it's all within the (not very
precise) wording of the Touch Events spec.
... implementations differ here already, regardless of
touch-action.
... I think you could formulate those interop questions without
bringing up touch-action.
... e.g. the Touch Events spec would specify whether
touchcancel is dispatched when scrolling starts.
... That's independent of the touch-action question.
... I agree with Olli that it would be nice to have this
written down somewhere. But I'm not sure how/where to do
that.
Zakim: who is talking
JR: I'm not sure if this needs an additional spec.
RB: Maybe it doesn't; I'm mostly
just concerned about the explicit mention of pointercancel in
the touch-action section of the spec.
... Would it make sense to just move that one line to a
different section of the PE spec?
... It could be a hook, so any other event system that wanted
to support touch-action could specify its equivalent
behavior.
JR: Yes, I think we could move that to 5.2.8.
RB: Another reason that could make sense is that consumers of pointer events might not use touch-action anywhere. But that behavior is still relevant even if the property is not used.
JR: I think you're right. I think
we can just lift that paragraph into the section that defines
pointercancel.
... I'd be okay with that if it makes it easier to write a
lightweight spec referencing just 9.1.
RB: We still have the problem of
all the details around how Touch Events respond to
scrolling.
... We've talked about that in the touch-events CG and
documented existing browser behavior.
OP: Sounds good to me.
... I just wanted to make sure we agree it should be documented
somewhere.
AB: So Jacob can take an action
to make that one change.
... Any objections?
[None]
<rbyers> scribenick: rbyers
AB: I'll be away for the next 2 weeks, if anyone wants to have a meeting they should notify Doug and group Monday early morning boston time
AV: I wonder if we should meet next week to finalize the test case
AB: If scott completes his action
by Monday then meeting on Tuesday sounds good to me
... Sounds like we have a plan to meet next Tuesday, topic:
reviewing the tests - blocked on Scott's action
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/RP/RB/ Found Scribe: Doug Found ScribeNick: shepazu Found Scribe: rbyers Inferring ScribeNick: rbyers WARNING: No scribe lines found matching previous ScribeNick pattern: <shepazu> ... Found ScribeNick: rbyers Found ScribeNick: mbrubeck Found ScribeNick: rbyers Scribes: Doug, rbyers ScribeNicks: shepazu, rbyers, mbrubeck Present: Art Jacob Asir Cathy Rick Matt Olli Scott Doug Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0007.html Got date from IRC log name: 15 Jul 2014 Guessing minutes URL: http://www.w3.org/2014/07/15-pointerevents-minutes.html People with action items: jrossi[End of scribe.perl diagnostic output]