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


<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

  1. find out from original poster what specific devices have this; spec it out and mark at risk pending implementations
  2. merging after the call
  3. Ted to submit PR and test
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/05/25 15:53:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Succeeded: s/Oli/Olli/
Succeeded: s/??/SG/
Succeeded: s/NavidZ?/NZ/
Succeeded: s/valid concern/valid concern for the larger issue of our desire to avoid hit testing for touch/
Succeeded: s/i can take one on/if no-one else is interested I can do it/
Succeeded: s/Oli: is there/DT: is there/
Found Scribe: patrick_h_lauke
Inferring ScribeNick: patrick_h_lauke
Found ScribeNick: patrick_h_lauke
Present: patrick_h_lauke NavidZ scott_gonzalez teddink smaug rbyers dtapuska

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


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

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

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]