Goals for TPAC PEWG face-to-face?

As discussed in the call today my personal goal for the TPAC F2F is to get
consensus on the plan for shipping an initial implementation in Chrome.
Our implementation is basically done, but we want to hold off shipping
until this group is comfortable with it.  We of course expect to continue
to iterate on the outstanding differences in implementation post-ship, but
once we ship there were be additional compat concerns that could constrain
changes.

Concretely I think this means achieving consensus on #8
<https://github.com/w3c/pointerevents/issues/8> and #61
<https://github.com/w3c/pointerevents/issues/61> (eg. by merging our
reduce-hit-tests
branch <https://github.com/w3c/pointerevents/tree/reduce-hit-tests> to
master).  Does anyone have any other design/compat concerns they feel
should block Chrome shipping an initial PointerEvents implementation?

As for getting to consensus on the reduce-hit-tests question, as promised
on the call, here's a summary of the status of the action items from the
face-to-face
<https://docs.google.com/document/d/1b8aJOJcGXakstFJslKl87QwvlFHhHwGbQfJwnUTBBHg/edit#>
in
July:


   -

   Chrome team to propose spec changes in a branch
   <https://github.com/w3c/pointerevents/issues/8#issuecomment-235944207>
   that precisely describe their model (implicit capture for touch, capture
   circumvents hit-testing).


Done for #8
<https://github.com/w3c/pointerevents/commit/3459b59bc647a5d89c0578811d7252d3892cda82>,
PR for #61 in review <https://github.com/w3c/pointerevents/pull/138>


   -

   Better understand the web compat implications of the different model
   -

      Try to figure out why Chrome sees only ~1% of page views on Windows
      install a pointer event listener, while Edge sees ~15%.
      -

         mustaq@ will add a UseCounter
         <https://bugs.chromium.org/p/chromium/issues/detail?id=631897> for
         a (dummy) navigator.pointerEnabled property and report data
on the list in
         a few weeks.


pointerEnabled (returning false) landed
<https://bugs.chromium.org/p/chromium/issues/detail?id=631897> in Chrome
54, enabled along with pointer events API (dev channel only). Data for the
past week shows ~0.7% of page views on Windows and ~2% on Android invoke
pointerEnabled (constrast with ~0.7% of page views on Windows and ~1.8% on
Android which install a pointer event listener despite pointerEnabled being
false). So this appears to rule out pointerEnabled as the reason usage on
Edge seems so much higher.

We know our absolute UseCounter values have some biases, so it's possible
this is just measurement error on our side (normally it's the relative
usage that matters so fixing the absolute values hasn't been a high
priority until recently). We should be able to test this in a few weeks.




   -

      Chrome to add a flag
      <https://bugs.chromium.org/p/chromium/issues/detail?id=632393> (if
      it’s not too hard) to switch to the Edge model for compat
testing purposes.


Flag <https://bugs.chromium.org/p/chromium/issues/detail?id=640700> for
disabling implicit capture now in canary, flag to enable boundary events
during capture expected to land by next week sometime.


   -

      Edge to add a flag to switch to the Chrome model, and explore testing
      / preview build with it enabled


On the call Ted said he expected "to have a machine with an Edge build that
implements the reduce-hit-tests branch by TPAC". Ted, does this mean code
landed (expected to hit an insider build in the future), or just a hacked
up custom build?


   -

      Chrome to continue it’s dev/canary-channel field trial (~1% of
      windows users) and report on any bugs identified where behavior differs
      from Edge


No new bugs reported since the face-to-face. Still seems to be highly
compatible.


   -

      Chrome to explore doing an (unusual) field trial on Android Beta
      builds to get some idea of the risk on mobile sites / touch-only devices.


In launch review - hoping for a decision in the next 1-2 weeks.


   -

   Explore adding APIs to help make the model more rational / reduce the
   risk of developer pain
   -

      Element.hasPointerCapture
      <https://github.com/w3c/pointerevents/issues/121> (v2-blocking)


Added to spec and implemented in Chrome.


   -

      Standardize CSS pseudoclass behavior for touch
      <https://github.com/w3c/pointerevents/issues/123> (future work)
      -

   Review status / compat data via PEWG list / calls by early/mid September
   -

   Aim to have consensus in time for PEWG meeting at TPAC (late Sept)
   - If that can be achieved, then the goal is for Chrome to ship in either
   M55 (branch early Oct, stable Dec) or M56 (branch mid Nov, stable end of
   Jan)