<scribe> Scribe: patrick_hlauke
<smaug> just a sec
<smaug> hmm, I can't hear anything..
we could hear you typing
Bo: had meeting with owner of trackpad API internally, potential additional scenario of using trackpad as signature. integration-wise, it gets hairy as you'd need a side channel from the human interface device and your app would end up fighting with the native/OS side
we don't have apps natively that consume raw data, only consume data after OS consumed it/made it available. but have had digital signature requests, but not acted on them yet
as we don't have native apps doing this, this can inform how pressing (or not) it would be for web platform / PE
mustaq: we have bugs open. we had issue with signature for pdf viewer and problem with passing things through
Bo: from MS perspective we don't have people asking for this, so would defer
Olli: agree we can close or at least remove v3 label
Patrick: we can close it now, worst case we can reopen in future if new use cases/insights emerge
Patrick: no further work has happened yet (may need NavidZ to confirm). we'll discuss next meeting
Patrick: seems that user wants overscroll behaviour/detection
mustaq: this doesn't fit the pointer event model as the pointer gets cancelled, would you bring it back later?
Bo: looks like starting a new sequence on overscroll
https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481
<ella> https://discourse.wicg.io/t/proposal-new-events-for-overscroll-and-scrollend/3481
https://navidz.github.io/overscroll-scrollend-events/ this 404s
<mustaq> From the linked post:
<mustaq> https://www.irccloud.com/pastebin/w98kSxsK/
Proposal
Dispatch the overscroll and scrollend events in addition to the scroll event to provide more states to the javascript code. Note that overscroll event needs a delta as while the user is overscrolling nothing changes (in terms of offsetX/Y) and hence the script will need the delta in the event to get more information.
<BoCupp> Is this the link for the alternative proposal? https://github.com/WICG/overscroll-scrollend-events
Patrick: that's probably it yes
Bo: there's discussion around pick a use case and show how developer uses the API, reverse the overscroll, etc
Patrick: conceptually, is this something for Pointer Events to handle, or do we want to defer to this proposed new spec?
mustaq: the assumption here is
that the pointer that gets cancelled is the one that comes
back
... how would the dev differentiate it from a different pointer
being down
Olli: use case needs to be implemented without touch action, websites would need to do it themselves
mustaq: ... we send an "uncancel" evenent (?) to the application for the same pointer. js gives control to browser, but then browser needs to give control back to JS ...
Olli: i don't think that's
feasible to do within PE
... they'll have to do the whole thing in JS, without
interacting (handing on/off) with user agent behavior
Bo: there's room though for using
browser smooth scrolling without having to replicate all this
in JS, but agree this seems less natural as treating it as
another pointerdown
... compared to what Navid proposes with new events and a
delta
Olli: does this apply to keyboard scrolling too. it's only for pointers, so should it be in pointer events
Patrick: it's about seeing if
it#s PE because it only happens with pointers, or do we look at
this as it's about scrolling
... can we overscroll with a mousewheel? can't overscroll with
keyboard
<mustaq> Ella: in Chrome no way to overscroll using mousewheel or keyboard
Bo: in the proposal for
overscroll it says it needs to take into consideration various
input methods
... getting back to question before, do we want to keep working
on this in PE or leave it at WICG? latter has more discussion,
and seems that this will touch on more than just pointers
Patrick: agree. Olli, mustaq, any objections?
no objections
Patrick: i'll close the issue and point to the minutes here. it may come back here once it's been discussed further in WICG
<mustaq> Next:
<mustaq> https://github.com/w3c/pointerevents/issues/191
Patrick: this sounds like it's a shortcut that happens at OS level unless an app explicitly opts into getting the buttons themselves rather than just commands
Bo: correct. users can't change
the command itself unless they use customisation software for
mouse/keyboard, but in principle yes apps can opt into
receiving the buttons
... signals from OS can also be cancelable, where the app gets
both the command and the button press and can decide what to
do
... we'd opt for option B
mustaq: concern about button
doing different things depending on where the user clicks
... but if it's only a small concern, we'd go for B
Olli: but is this web
compatible?
... i.e. pages could cancel all button down, but only process
"regular" buttons, which would then prevent the expected
navigation command/action
Bo: how would we solve this? have sites opt in?
<ella> https://www.chromestatus.com/feature/5088301178421248
PAtrick: i don't think we do any kind of opt in for other stuff, other than via touch-action directives. worth running an experiment/analysing web content/sites?
mustaq: i believe we now allow cancelling (bug above posted by ella)
Olli: should the default event be on down or up or click or auxclick
ella: we have a test page
<ella> https://jsbin.com/cawumemaqu/edit?html,output
<ella> from crbug.com/852709
Olli: think we need more info on how OSs work right now/when they fire the default. could expect safari folks wouldn't want to do anything that doesn't map to MacOS behavior
mustaq: we've not received complains about the new behavior (?)
Olli: would be nice to know exact behavior chrome has right now
Patrick: we can leave it for next time
<NavidZ_> https://github.com/w3c/pointerevents/issues/203
[discussion on starting merging extension into main doc in a branch for v3 - Navid will take care of this]
Bo: another topic we'd like to
look at is Enable direct pen and touch to have different
touch-action behavior https://github.com/w3c/pointerevents/issues/203
... [explains scenarios where you'd want specific control over
pen rather than all pointers with touch-action just now]
... written an explainer with more use cases
Patrick: this kind of highlights
the misnomer of touch-action which actually applies to all
pointers (in theory at least, UAs don't do special things on
mouse, but they do stuff for touch and pen)
... i mean we could do some heuristic/mapping (if only
touch-action is there, treat it like "high-level" action - like
pointer-event-action - but otherwise only apply it to touch if
there's a pen-action)
<mustaq> Dev proposal here: https://github.com/w3c/pointerevents/issues/203#issuecomment-299578767
Navid: agree we could for compat
provide some kind of compat way. or do we want a breaking
change
... in terms of forward compatibility, where more input types /
pointers may emerge, it feels weird to go down the
touch-action, pen-action, etc way of having to create a new css
property. if we are inventing/expanding the css property, then
maybe good to invent a new css thing that can apply to
everything, and then merge the touch action values as
legacy
Patrick: agree we want to look at a more input agnostic approach
Bo: i can take this away and see if we can come up with something more general
Navid: may also want to talk to CSS WG. maybe discuss further at TPAC?
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: patrick_h_lauke BoCupp smaug ella mustaq NavidZ Navid No ScribeNick specified. Guessing ScribeNick: patrick_h_lauke Found Scribe: patrick_hlauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019JulSep/0011.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]