Draft minutes: 8 June 2016 call

Hi All,

draft minutes from the last PEWG call are available at

https://www.w3.org/2016/06/08-pointerevents-minutes.html

and copied below.

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

W3C
- DRAFT -

SV_MEETING_TITLE

08 Jun 2016

See also: IRC log

Attendees

Present
Mustaq_Ahmed, Rick_Byers, patrick_h_lauke, teddink, Navidz, 
Scott_Gonzalez, shepazu, dtapuska
Regrets
Chair
patrick_h_lauke
Scribe
rbyers
Contents

Topics
next steps for FPWD
Add digitizer/pen twist / Add digitizer/pen barrel pressure
Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise
Summary of Action Items
Summary of Resolutions
<patrick_h_lauke> scribe: rbyers
next steps for FPWD

PL: Doug, have you had a chance to look at the e-mail about FPWD?
... next step is to send it to the chairs list?

<patrick_h_lauke> 
https://lists.w3.org/Archives/Public/public-pointer-events/2016AprJun/0271.html
DS: Yes

PL: Reasonable to propose July, send mail to PLH and chairs

DS: Yes, or I can send if you prefer

PL: I'll send it. Anyone else have feedback, eg. on July publication? 
Rick already gave +1.

<teddink> July sounds good to me to get somethig out there.
PL: don't need to have everything ready
... anyone prefer pointer-events-2 vs. pointerevents2

DS: I'd argue for consistency in naming
... what's the current one

PL: "pointerevents"

DS: I'd go with "pointerevents2" then

TD: No objections

RESOLUTION: Patrick to e-mail PLH/chairs with FPWD for pointerevents2

PL: Doug and then you update the W3C site?

DS: Yes

Add digitizer/pen twist / Add digitizer/pen barrel pressure

<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/79
<patrick_h_lauke> https://github.com/w3c/pointerevents/pull/81
PL: I've made some basic pull requests for these
... barrel pressure does look a little more specific than twist
... what are people's thoughts?

MA: for twist case, proposal was 0-360. Why not -180 to +180 to be 
consistent with tilt?
... makes more sense to me

RB: What did we do for touch events rotation?

PL: For me just basing on what Microsoft API does
... just mapping to that, but I don't have strong preference

MA: for touch events it's between -0 and 90 because it's contact area

<patrick_h_lauke> reference for MS API 
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.input.pointerpointproperties.twist?f=255&MSPPError=-2147217396
RB: right that is very different (Even though Android confuses the two) 
- my mistake bringing it up

MA: floating point seems overkill

NZ: can we just change the bracket to be exclusive?

<patrick_h_lauke> [0,360[
<NavidZ> [0,360)
<mustaq> I was proposing (-180,180]
Android: 
https://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION

<teddink> Does iOS have this property defined for the Apple Pencil?
RB: I don't thing the details matter

No, apple pencil doesn't have tilt

MA: tilt is integer, why not twist?

RB: Good point, should just be consistent with tilt

PL: Ok makes sense to me
... I trust your math, but will people understand the difference in brakets?

NZ/MA: writing in words is better

<patrick_h_lauke> [0,359]?
RB: If we agree we want to be consistent with tilt, this is trivial

<teddink> I agree - words is easier to understand and clear for everyone.
RB: i.e. integer

PL: Ok, will do that. Everyone happy?

NZ: undefined vs. zero

RB: we should be consistent with our decision on pressure
... benefits either way, but since Edge is already shipping 0 and we 
have InputDeviceCapabilities where we can attach 'hasPressure' etc. that 
seems best

PL: OK so twist seems fairly straight forward, but barrel pressure seems 
more specific

RB: there was some talk of the more generic term "tangential pressure" 
but USB HID spec says "barrell pressure"

DS: So does iOS pencil have tilt?

RB: No

DS: For formatting, we should ask CSSWG. Having consistency across 
different specs is a good idea.
... CSS has a complex way of expressing units
... this doesn't seem consistent with that

https://drafts.csswg.org/css-transforms/#two-d-transform-functions

TD: My iOS question was about twist not tilt

RB: Right sorry, no twist either. Just pressure really IIRC.

<patrick_h_lauke> 
https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9_1.html#//apple_ref/doc/uid/TP40016572-DontLinkElementID_3
RB: Yes sorry, looks like I was wrong.

DS: So this is an area where pointer events could expose additional 
details in iOS scenarios that touch events don't
... this is key to our mission of exposing all the native capabilities 
to the web
... an opportunity for us to use what we've done instead of do 
Apple-specific

PL: Makes sense, though they may want to add to touch events spec 
instead. Politics involved.

<patrick_h_lauke> sorry ted missed you on the queue there
<teddink> No worries - I just spoke up on my own!
DS: Could Chrome on iOS / Mac expose stylus properties?

RB: Not on iOS (Apple store restriction to use built-in WebKit), but yes 
on MacOS

<patrick_h_lauke> opportunity for Chrome on OS X to expose if using 
wacom tablets perhaps?
RB: Ok I think we all agree on this - the properties used by standard 
Microsoft, Apple and Samsung stylus hardware are already in the PE spec.
... the outstanding questions are the more obscure properties like 
twist, barrel pressure

TD: Agreed. The problem is when the underlying platform doesn't have a 
standard API for these properties.

<patrick_h_lauke> barrel pressure is standard documented HID 
https://github.com/w3c/pointerevents/issues/70
<scribe> .. ongoing risk of interop issues
PL: when part of HID spec that should be enough right?

<patrick_h_lauke> Rick: HID spec is low level, so Ted's point is that 
device drivers abstract on top of that, so we need to be careful
RB: I agree with Ted, I don't want Chrome to have any code for specific 
device drivers - only talk to the underlying standard OS APIs.
... so if twist isn't exposed by a standard Windows API then Chrome 
wouldn't support it on Windows.

DS: When someone writes an input-level driver, does it talk directly to 
apps or indirectly via OS APIs?

TD: Yes. We want apps to talk to the standard OS APIs. But drivers do 
sometimes add new properties and expose it directly, encouraging apps to 
talk directly to the driver.

<patrick_h_lauke> so is the risk here that HID spec is volatile? that 
APIs don't expose all HID ... points?
DS: All the things we're talking about so far are possible to expose via 
the OS

?

TD: Yes sure, it's just not today on Windows

<patrick_h_lauke> Rick: good discussion, principle i'd like to apply: in 
Chrome we don't implement something that's not hanging off of an OS API
<patrick_h_lauke> Rick: so we shouldn't add things to PE API unless 
there's a concrete API on at least one platform
<patrick_h_lauke> DS: i love the concrete, precise, objective way to 
decide what can/should be implemented
<patrick_h_lauke> DS: friendly amendments: we could make that explicit 
in spec (these are constraints we worked under, chain of implication)
RB: I propose we say we only standardize properties when they're 
available in the OS standard input API on SOME OS supported by major 
browsers (eg. Windows or Android)

<patrick_h_lauke> DS: then we can include things like barrel pressure, 
but mark at risk "pending having it exposed on OS"
DS: Could include things like barrelPressure but mark them as at risk 
pending OS exposure
... has happened in the past that something that's a feature of the web 
platform has been pushed into OS level things

<patrick_h_lauke> +1 to DS
DS: shouldn't assume we can't influence the OS

<patrick_h_lauke> RB: i agree, but my preference would be to keep github 
issue instead of adding to spec and marking as at risk
<patrick_h_lauke> RB: but i get your point that it gets more 
exposure/official
DS: I feel like having it in the spec gives it more exposure

<patrick_h_lauke> DS: we send signals to larger community
DS: discoverability is much higher

<patrick_h_lauke> +1
<patrick_h_lauke> CONCLUSION: twist ok, barrel pressure we decide 
further on github (investigate if implemented anywhere)
PL: Sorry, thought these would be fast.

Spec implies lost/gotpointercapture is delayed until the next pointer 
event but Edge does otherwise

<patrick_h_lauke> (https://github.com/w3c/pointerevents/issues/32)
NZ: So Ted described that Edge does send events immediately when caused 
by a pointerdown handler
... but the same thing happens for pointermove
... maybe not as common as capturing on pointerdown
... also on Edge, a few seconds after gotpointercapture a synthetic 
pointermove is sent if there hasn't already been one
... So I'm trying to match Edge behavior in my PR

TD: The reason we made the change specific for pointerdown is that there 
were some specific sites where we'd see issues otherwise
... that was for gotpointercapture. we specifically did not make the 
same change around lostpointercapture
... The reason we're seeing some synthetic pointermoves is related to 
debouncing we're doing from pointer messages we get from the OS. The OS 
sometimes sends us heartbeat messages, but we try to eliminate them when 
they don't matter.
... We think we have a bug where we'll send the _first_ such heartbeat 
message but debounce the rest
... I have a bug to track this, will get you a public link

NZ: Ok, so the original concern that delaying gotpointercapture might 
cause some problems
... should we just say we send it right away in the pointerdown case?

RB: Physical events (down, up, move) seem fundamentally different from 
the logical events (got/lostpointercapture, enter, leave, over, out). 
Send immediately for the former not the latter?

NZ: If we just prevent immediate capturing within the specific case that 
should be enough. Should we just prefer to send right away unless we 
know we should delay.

TD: Yes I think that's OK, I'll check with my team

NZ: Ok that's the intent of this PR: 
https://github.com/w3c/pointerevents/pull/76

TD: So that would send lostpointercapture immediately as well?
... I'm not sure that PR is specific to physical events, it's more 
generic (anything other than got/lost).

NZ: As of now we send boundary events during capture so have to be 
careful to avoid infinite loops. But they're not all problematic, only 
those that are a result of "process pending pointer capture".
... that's what I was trying to do.

MA: I agree with Rick, should just be physical cases

NZ: But pointerleave is actually sometimes a "physical" case, including 
special cases where there is no pointermove (eg. when the window becomes 
occluded)
... In terms of lostpointercapture, there are also some cases where Edge 
sends this right away. Eg. when the finger leaves the screen. The 
current spec says that when the finger is released, lostpointercapture 
shouldn't be sent until the NEXT event for that pointer ID (which could 
be never)
... so that's broken as well in the current spec.

RB: Agree that we have to fix the lostpointercapture case as well - at 
least for the implicit release case

TD: Ok I'll check with my dev team

<patrick_h_lauke> CONCLUSION: continue to iterate on PR which seems to 
capture the right thing. Ted to check with devs
PL: Out of time, let's keep iterating on the remaining points on GitHub

RB: I can't make next week (Google folks travelling)
... discussion among a bunch of folks

PL: Ok let's meet in two weeks instead

Summary of Action Items

Summary of Resolutions

Patrick to e-mail PLH/chairs with FPWD for pointerevents2
[End of minutes]

-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 9 June 2016 00:10:58 UTC