<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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: rbyers
Inferring ScribeNick: rbyers
Present: Mustaq_Ahmed Rick_Byers patrick_h_lauke teddink Navidz Scott_Gonzalez shepazu dtapuska

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 08 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/08-pointerevents-minutes.html
People with action items: