15:00:54 <RRSAgent> RRSAgent has joined #pointerevents
15:00:54 <RRSAgent> logging to http://www.w3.org/2016/06/08-pointerevents-irc
15:01:47 <mustaq> present+ Mustaq_Ahmed
15:02:03 <rbyers> present+ Rick_Byers
15:02:08 <patrick_h_lauke> chair: patrick_h_lauke
15:02:13 <patrick_h_lauke> present+ patrick_h_lauke
15:02:19 <teddink> present+ teddink
15:02:34 <patrick_h_lauke> scribe: rbyers
15:02:48 <NavidZ> present+ Navidz
15:03:13 <patrick_h_lauke> topic: next steps for FPWD
15:03:27 <scott_gonzalez> present+ Scott_Gonzalez
15:03:31 <shepazu_> present+ shepazu
15:03:46 <rbyers> PL: Doug, have you had a chance to look at the e-mail about FPWD?
15:03:54 <dtapuska> dtapuska has joined #pointerevents
15:04:04 <rbyers> .. next step is to send it to the chairs list?
15:04:12 <dtapuska> present+ dtapuska
15:04:34 <patrick_h_lauke>  https://lists.w3.org/Archives/Public/public-pointer-events/2016AprJun/0271.html
15:05:17 <rbyers> DS: Yes
15:05:37 <rbyers> PL: Reasonable to propose July, send mail to PLH and chairs
15:05:43 <rbyers> DS: Yes, or I can send if you prefer
15:06:03 <rbyers> PL: I'll send it.  Anyone else have feedback, eg. on July publication?  Rick already gave +1.
15:06:08 <teddink> July sounds good to me to get somethig out there.
15:06:09 <rbyers> .. don't need to have everything ready
15:06:27 <rbyers> .. anyone prefer pointer-events-2 vs. pointerevents2
15:06:33 <rbyers> DS: I'd argue for consistency in naming
15:06:41 <rbyers> .. what's the current one
15:06:46 <rbyers> PL: "pointerevents"
15:06:58 <rbyers> DS: I'd go with "pointerevents2" then
15:07:16 <rbyers> TD: No objections
15:07:40 <rbyers> RESOLUTION: Patrick to e-mail PLH/chairs with FPWD for pointerevents2
15:08:02 <rbyers> PL: Doug and then you update the W3C site?
15:08:05 <rbyers> DS: Yes
15:08:29 <patrick_h_lauke> TOPIC: Add digitizer/pen twist /  Add digitizer/pen barrel pressure
15:08:44 <patrick_h_lauke> https://github.com/w3c/pointerevents/pull/79
15:08:49 <patrick_h_lauke> https://github.com/w3c/pointerevents/pull/81
15:08:56 <rbyers> PL: I've made some basic pull requests for these
15:09:07 <rbyers> .. barrel pressure does look a little more specific than twist
15:09:10 <rbyers> .. what are people's thoughts?
15:09:39 <rbyers> MA: for twist case, proposal was 0-360.  Why not -180 to +180 to be consistent with tilt?
15:09:58 <rbyers> .. makes more sense to me
15:10:06 <rbyers> RB: What did we do for touch events rotation?
15:10:37 <rbyers> PL: For me just basing on what Microsoft API does
15:10:52 <rbyers> .. just mapping to that, but I don't have strong preference
15:11:27 <rbyers> MA: for touch events it's between -0 and 90 because it's contact area
15:11:33 <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
15:11:42 <rbyers> RB: right that is very different (Even though Android confuses the two) - my mistake bringing it up
15:11:55 <rbyers> MA: floating point seems overkill
15:12:07 <rbyers> NZ: can we just change the bracket to be exclusive?
15:12:52 <patrick_h_lauke> [0,360[
15:13:03 <NavidZ> [0,360)
15:13:31 <mustaq> I was proposing (-180,180]
15:13:49 <rbyers> Android: https://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION
15:14:36 <teddink> Does iOS have this property defined for the Apple Pencil?
15:14:39 <rbyers> RB: I don't thing the details matter
15:14:51 <rbyers> No, apple pencil doesn't have tilt
15:14:59 <rbyers> MA: tilt is integer, why not twist?
15:15:23 <rbyers> RB: Good point, should just be consistent with tilt
15:15:28 <rbyers> PL: Ok makes sense to me
15:16:19 <rbyers> PL: I trust your math, but will people understand the difference in brakets?
15:16:31 <rbyers> NZ/MA: writing in words is better
15:16:48 <patrick_h_lauke> [0,359]?
15:16:52 <rbyers> RB: If we agree we want to be consistent with tilt, this is trivial
15:16:54 <teddink> I agree - words is easier to understand and clear for everyone.
15:17:03 <rbyers> .. i.e. integer
15:17:10 <rbyers> PL: Ok, will do that.  Everyone happy?
15:17:17 <rbyers> NZ: undefined vs. zero
15:18:01 <rbyers> RB: we should be consistent with our decision on pressure
15:18:28 <rbyers> .. benefits either way, but since Edge is already shipping 0 and we have InputDeviceCapabilities where we can attach 'hasPressure' etc. that seems best
15:18:47 <rbyers> PL: OK so twist seems fairly straight forward, but barrel pressure seems more specific
15:19:04 <shepazu> q+
15:19:16 <rbyers> RB: there was some talk of the more generic term "tangential pressure" but USB HID spec says "barrell pressure"
15:19:59 <rbyers> DS: So does iOS pencil have tilt?
15:20:00 <rbyers> RB: No
15:20:28 <rbyers> DS: For formatting, we should ask CSSWG.  Having consistency across different specs is a good idea.
15:20:37 <rbyers> .. CSS has a complex way of expressing units
15:20:43 <rbyers> .. this doesn't seem consistent with that
15:21:29 <teddink> q+
15:22:00 <rbyers> https://drafts.csswg.org/css-transforms/#two-d-transform-functions
15:22:35 <rbyers> TD: My iOS question was about twist not tilt
15:22:49 <rbyers> RB: Right sorry, no twist either.  Just pressure really IIRC.
15:22:57 <patrick_h_lauke> https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9_1.html#//apple_ref/doc/uid/TP40016572-DontLinkElementID_3
15:24:13 <rbyers> RB: Yes sorry, looks like I was wrong.
15:25:24 <rbyers> DS: So this is an area where pointer events could expose additional details in iOS scenarios that touch events don't
15:25:58 <rbyers> .. this is key to our mission of exposing all the native capabilities to the web
15:26:31 <rbyers> .. an opportunity for us to use what we've done instead of do Apple-specific
15:26:59 <rbyers> PL: Makes sense, though they may want to add to touch events spec instead.  Politics involved.
15:27:14 <teddink> q-
15:27:57 <patrick_h_lauke> sorry ted missed you on the queue there
15:28:15 <teddink> No worries - I just spoke up on my own!
15:28:29 <rbyers> DS: Could Chrome on iOS / Mac expose stylus properties?
15:28:44 <rbyers> RB: Not on iOS (Apple store restriction to use built-in WebKit), but yes on MacOS
15:28:49 <patrick_h_lauke> opportunity for Chrome on OS X to expose if using wacom tablets perhaps?
15:30:19 <rbyers> 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.
15:30:32 <rbyers> .. the outstanding questions are the more obscure properties like twist, barrel pressure
15:30:50 <rbyers> TD: Agreed.  The problem is when the underlying platform doesn't have a standard API for these properties.
15:31:16 <shepazu> q+
15:31:16 <patrick_h_lauke> barrel pressure is standard documented HID https://github.com/w3c/pointerevents/issues/70
15:31:18 <rbyers> .. ongoing risk of interop issues
15:31:45 <rbyers> PL: when part of HID spec that should be enough right?
15:32:32 <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
15:33:02 <rbyers> 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.
15:33:20 <rbyers> .. so if twist isn't exposed by a standard Windows API then Chrome wouldn't support it on Windows.
15:34:02 <rbyers> DS: When someone writes an input-level driver, does it talk directly to apps or indirectly via OS APIs?
15:34:59 <rbyers> 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.
15:35:09 <patrick_h_lauke> so is the risk here that HID spec is volatile? that APIs don't expose all HID ... points?
15:35:29 <rbyers> DS: All the things we're talking about so far are possible to expose via the OS
15:35:31 <rbyers> ?
15:35:37 <rbyers> TD: Yes sure, it's just not today on Windows
15:36:14 <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
15:36:36 <patrick_h_lauke> Rick: so we shouldn't add things to PE API unless there's a concrete API on at least one platform
15:37:31 <patrick_h_lauke> DS: i love the concrete, precise, objective way to decide what can/should be implemented
15:38:02 <patrick_h_lauke> DS: friendly amendments: we could make that explicit in spec (these are constraints we worked under, chain of implication)
15:38:02 <rbyers> 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)
15:38:49 <patrick_h_lauke> DS: then we can include things like barrel pressure, but mark at risk "pending having it exposed on OS"
15:38:50 <rbyers> DS: Could include things like barrelPressure but mark them as at risk pending OS exposure
15:39:06 <rbyers> .. has happened in the past that something that's a feature of the web platform has been pushed into OS level things
15:40:06 <patrick_h_lauke> +1 to DS
15:40:09 <rbyers> .. shouldn't assume we can't influence the OS
15:40:53 <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
15:41:03 <patrick_h_lauke> RB: but i get your point that it gets more exposure/official
15:41:12 <rbyers> DS: I feel like having it in the spec gives it more exposure
15:41:14 <patrick_h_lauke> DS: we send signals to larger community
15:41:33 <rbyers> .. discoverability is much higher
15:41:37 <patrick_h_lauke> +1
15:42:12 <patrick_h_lauke> CONCLUSION: twist ok, barrel pressure we decide further on github (investigate if implemented anywhere)
15:42:34 <rbyers> PL: Sorry, thought these would be fast.
15:42:45 <patrick_h_lauke> TOPIC: Spec implies lost/gotpointercapture is delayed until the next pointer  event but Edge does otherwise
15:42:50 <patrick_h_lauke> (https://github.com/w3c/pointerevents/issues/32)
15:43:16 <rbyers> NZ: So Ted described that Edge does send events immediately when caused by a pointerdown handler
15:43:33 <rbyers> .. but the same thing happens for pointermove
15:43:45 <rbyers> .. maybe not as common as capturing on pointerdown
15:44:26 <rbyers> .. also on Edge, a few seconds after gotpointercapture a synthetic pointermove is sent if there hasn't already been one
15:45:09 <rbyers> .. So I'm trying to match Edge behavior in my PR
15:46:21 <rbyers> TD: The reason we made the change specific for pointerdown is that there were some specific sites where we'd see issues otherwise
15:46:39 <rbyers> .. that was for gotpointercapture.  we specifically did not make the same change around lostpointercapture
15:47:18 <rbyers> .. 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.
15:47:43 <rbyers> .. We think we have a bug where we'll send the _first_ such heartbeat message but debounce the rest
15:47:55 <rbyers> .. I have a bug to track this, will get you a public link
15:48:17 <rbyers> NZ: Ok, so the original concern that delaying gotpointercapture might cause some problems
15:48:30 <rbyers> .. should we just say we send it right away in the pointerdown case?
15:49:47 <rbyers> 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?
15:50:53 <rbyers> 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.
15:51:02 <rbyers> TD: Yes I think that's OK, I'll check with my team
15:51:29 <rbyers> NZ: Ok that's the intent of this PR: https://github.com/w3c/pointerevents/pull/76
15:51:59 <rbyers> TD: So that would send lostpointercapture immediately as well?
15:52:41 <rbyers> .. I'm not sure that PR is specific to physical events, it's more generic (anything other than got/lost).
15:53:35 <rbyers> 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".
15:53:52 <rbyers> .. that's what I was trying to do.
15:54:16 <rbyers> MA: I agree with Rick, should just be physical cases
15:55:03 <rbyers> NZ: But pointerleave is actually sometimes a "physical" case, including special cases where there is no pointermove (eg. when the window becomes occluded)
15:56:20 <rbyers> NZ: 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)
15:56:55 <rbyers> .. so that's broken as well in the current spec.
15:57:14 <rbyers> RB: Agree that we have to fix the lostpointercapture case as well - at least for the implicit release case
15:57:24 <rbyers> TD: Ok I'll check with my dev team
15:57:52 <patrick_h_lauke> CONCLUSION: continue to iterate on PR which seems to capture the right thing. Ted to check with devs
15:58:21 <rbyers> PL: Out of time, let's keep iterating on the remaining points on GitHub
15:59:11 <rbyers> RB: I can't make next week  (Google folks travelling)
16:00:01 <rbyers> .. discussion among a bunch of folks
16:00:06 <rbyers> PL: Ok let's meet in two weeks instead
16:01:03 <patrick_h_lauke> rrsagent, generate minutes
16:01:03 <RRSAgent> I have made the request to generate http://www.w3.org/2016/06/08-pointerevents-minutes.html patrick_h_lauke
16:01:29 <patrick_h_lauke> rrsagent, set logs world-visible
16:01:42 <patrick_h_lauke> rrsagent, stop