Draft minutes: 2016 May 25 call

Hi All,

draft minutes from the PEWG call on 25 May are available at

https://www.w3.org/2016/05/25-pointerevents-minutes.html

and copied below.

If you have any comments, corrections, etc., please reply to this email 
by 31 May. In the absence of any changes, these minutes will be 
considered approved.

W3C
- DRAFT -

SV_MEETING_TITLE

25 May 2016

See also: IRC log

Attendees

Present
patrick_h_lauke, NavidZ, scott_gonzalez, teddink, smaug, rbyers, dtapuska
Regrets
Chair
SV_MEETING_CHAIR
Scribe
patrick_h_lauke
Contents

Topics
Add additional digitizer/pen attributes: twist (rotation) 
https://github.com/w3c/pointerevents/issues/25
Make width/height default to 1, remove UA "guessing"/faking geometry 
https://github.com/w3c/pointerevents/pull/69
Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise https://github.com/w3c/pointerevents/issues/32
Should a captured pointer send boundary events by default? 
https://github.com/w3c/pointerevents/issues/61 (linked to 
https://github.com/w3c/pointerevents/issues/39 and 
https://github.com/w3c/pointerevents/issues/8)
Mouse Event compatibility model for touch is incompatible with current 
practice https://github.com/w3c/pointerevents/issues/7 - should we add 
gesture-based compat mouse events for touch to the spec?
FPWD question
Summary of Action Items
Summary of Resolutions
<scribe> scribe: patrick_h_lauke
<teddink> +present teddink
Add additional digitizer/pen attributes: twist (rotation) 
https://github.com/w3c/pointerevents/issues/25

<shepazu> scribenick: patrick_h_lauke
Add additional digitizer/pen attributes: barrel pressure (tangential 
pressure) https://github.com/w3c/pointerevents/issues/70

PL: did trawl through github, these seem low hanging fruit
... do we agree in principle?

RB: as long as there's at least one device that supports these on at 
least one platform, Blink would be happy to implement

Ted: we agree in principle, as long as it's available in Windows, but 
not opposed to property at all

Olli: how many % of users will use this feature?

??: it would not be a priority to implement

RB: but if no engine implements it, there won't be user uptake

Ted: it's worth conversation to discuss how useful it is to web developers

Doug?: we should put the question to the issue about what device support 
currently is and what use cases are

RB: it's chicken and egg - if not implemented, web devs won't even think 
of use cases; in principle, the web should have same power/functionality 
that native has

SG: we can spec it, it's then up to browsers to implement it.

Doug: from standards/process perspective, if we add to spec, and nobody 
implements it, we can mark it at risk when we come to CR

but as we now have language for it, we can defer it to future versions 
of the spec until support does exist

actions to do: find out from original poster what specific devices have 
this; spec it out and mark at risk pending implementations

PL: i think the device was wacom...airbrush

RB: link to store where i can buy it would be helpful
... i met with wacom folks few months ago and asked if they have other 
properties that matter to them. they listed the ID which we rejected on 
privacy grounds

RB/Doug: we'll reach out to Wacom to participate

RESOLUTION: find out from original poster what specific devices have 
this; spec it out and mark at risk pending implementations

Make width/height default to 1, remove UA "guessing"/faking geometry 
https://github.com/w3c/pointerevents/pull/69

PL: discussed on github/list, anybody disagree?

not hearing any disagreements

RESOLUTION: merging after the call

Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise https://github.com/w3c/pointerevents/issues/32

RB: this is more for Ted - can you explain what Edge does?

Ted: working on proposed change, but got put on backburner. change is 
going to match current Edge behavior, there's a bit of history from 
previous implementation. actively working on it and will send a PR in 
next week or so.

to rick's point: it's also intention to submit a test to make sure we're 
interoperable

RESOLUTION: Ted to submit PR and test

RB: sometimes it's quite complicated due to historical reasons for 
implementations etc, so having tests will help a lot

(general agreement)

Should a captured pointer send boundary events by default? 
https://github.com/w3c/pointerevents/issues/61 (linked to 
https://github.com/w3c/pointerevents/issues/39 and 
https://github.com/w3c/pointerevents/issues/8)

PL: can we move forward, or are we at a stalemate?

NZ: we were waiting for Jacob's use case, we're waiting on feedback on 
our proposed solution. Ted any feedback

solution being: doing manual X/Y checking rather than relying on hit 
testing/events

Ted: it's a viable technical solution; could do some A/B testing in the 
summer to see how interoperable that change would be to the spec. when i 
first started with PE, one of first things that drew me to it was that 
as developer i don't care about what source of input is, i just listen 
to PE and i'm done - no "if it's touch it has this slightly different 
behavior..."

trying to make sure we don't lose sight of this high-level goal/concept 
when we're talking about making fundamental changes in behavior for 
certain pointer types in the context of the APIs

RB: it's a good/valid concern for the larger issue of our desire to 
avoid hit testing for touch. the particular proposal that Navid has 
doesn't have different behavior for different pointers

NZ: basically we deal with all pointers the same. it just relates to 
pointer capture - if you do that, there won't be hit test on the element

there won't be any complications for transitions/events (pointerenter, 
pointerleave, etc)

RB: we were debating developer ergonomics, how developers can implement 
the proposed use case easily. may be best for us to just code up the 
actual example (mail app example ted sent to list/github)

that will make it easier to evaluate ergonomics

Ted: done code for example 1, need volunteers for 2 and 3

RB: if no-one else is interested I can do it

SG: i can take that on too

CONCLUSION: scott to make example code samples for different potential 
approaches so we can debate more concretely how ergonomic this change 
may be for devs

<NavidZ> https://github.com/w3c/pointerevents/issues/8
NZ: beyond capture, this related issue has both the notion of not hit 
testing when pointer captured, and...[missed] touch

RB: when we talked about this before it was blocked on compat data
... number one thing we need is data

DT: is there compat data that microsoft can provide?

<smaug> (that wasn't me)
RB: hopefully microsoft can collect data? anything in time for july?

(sorry smaug, my voice recognition is shockingly bad)

Ted: i'd have to ask around

CONCLUSION: ted to check if any compat data is available/can be 
collected, then discuss further

RB: as soon as we feel we have major issues fixed, we (blink) can put PE 
behind experimental flag and get more reports from users/devs

Mouse Event compatibility model for touch is incompatible with current 
practice https://github.com/w3c/pointerevents/issues/7 - should we add 
gesture-based compat mouse events for touch to the spec?

<dtapuska> that was me about the compat data question
RB: do we only do this behavior for touch?
... i believe that's what Edge does. if you enable touch event support 
in edge for desktop, you get ... [missed it]

Chrome does same as Edge currently

ted's comment is that when touch events are disabled it follows the 
model currently in spec

so question is: do we want to split out "if the browser supports touch, 
use this model; otherwise, use that model"

Ted: there is ongoing debate with each release if we enable touch events 
on desktop

RB: maybe we should do same and disable touch on desktop

maybe: if pointertype is touch and touch events are supported, use this 
behavior. otherwise, ...

i'd support changing spec to match Edge behavior, which Chrome is matching

Ted: easiest going forward. do we need to worry about Mozilla/Firefox?

Oli: currently touch events are enabled in nightlies on windows, but 
there have been compat issues similar to what chrome has experienced

RB: so should we initially update spec to match reality in Edge/Chrome?

ted do you know if there are any other gestures that fire mouse events 
beyond tap and long-tap gestures?

Ted: i'd have to ask / poke around in code, but not aware of any

RB: another area where tests would be nice
... patrick keeps telling us this matters to devs

PL: well it matters to me

<NavidZ> https://github.com/w3c/pointerevents/pull/56
RB: who wants to own this / make a PR?

NZ: we have THIS pull request that addresses this area

RB: missed this one, unless anybody on call has concerns, we can land this?

PL: not hearing any disagreement, so probably good to go ahead

RB: this was area where spec didn't match Edge, but there was some bug. 
would be good to know what Edge's behavior would be once bug fixed

Ted: it is our intention to behave the way Mustaq wrote up the PR

but we were cautious on the discussion as it wasn't clear WHEN the bug / 
behavior can be addressed

RB: all our changes are tentative until all browsers implement anyway. 
will review once more

CONCLUSION: Rick to review and merge

RB: anybody interested in owning the issue of mouse compat?

it's not urgent, not blocking

NZ: i'd be interested

PL: AOB?

RB: anybody played with chrome's PE implementation yet?

Ted: yes, and we sent you some emails

RB: appreciated

FPWD question

PL: at what point can we start with getting the FPWD gears in motion?

(discussion about when it's appropriate to request FPWD, needing to 
update intro/changelog, but not to worry too much about how "stable" the 
spec is)

Summary of Action Items

Summary of Resolutions

find out from original poster what specific devices have this; spec it 
out and mark at risk pending implementations
merging after the call
Ted to submit PR and test

Received on Wednesday, 25 May 2016 16:09:25 UTC