<scribe> Scribe: patrick_h_lauke
<smaug> webex is so not working for me
we'll wait for you smaug
Navid: proposal that microsoft had to send click/auxclick etc as pointer events
chrome has this behind experimental flag
for a few months
not had regression/bug reports, either because they're fine or low usage
we actually went with more aggressive version, where click etc are actual PE with fractional coordinates
we should define what it means for the other properties in PE
e.g. pointerType, if it comes from the keyboard
we could set to empty string
need to come up with a number for pointerId
wonder if we should say pointerId '0' value is the "we don't know" origin/value (e.g. generated by keyboard)
wondering what others think about that
we have normative language about pointerId can be recycled/reused. what happens then with click that comes after pointerup/pointerdown/etc
define WHEN ids can be recycled (until the whole event sequence is dispatched, including compat mouse events and click)
Olli: right now pointerId zero can be used for anything else so can't really use it
gecko uses zero already so can't be made special just now
wonder if we should use max value (it's LONG not Unsigned). could we use "-1" ?
Navid: we should double-check with other implementations if they ever assign negative pointerId
Olli: sounds like a good initial idea [pointerType empty and pointerId=-1]
Patrick: also like conceptually that pointerId="-1" kind of implies "this is (likely) not an actual pointer" as it feels conceptually a bit dirty that keyboard would fire a pointer event
Navid: ok, we'll run a test in
chrome, do a PR to spec, and we look if we get regressions
etc
... other topic discussed was longer discussion from Daniel
Libby about pointer event trail - he filed issue about it in
GH
asking underlying API to generate trail under pointer
[gives more details about the proposal - web app declaratively requesting platform draw a particular trail with certain characteristics]
reduced latency of this approach
saw demo on iPad at 120Hz
and on MS tablets. just drawing "shadows"
half of latency on Surface (at 50Hz) compared to iPad (120Hz)
but if only on windows, not the way to go
don't recall if Apple said they have similar API
Google plan to talk to Android etc platform to check if such a low-level API that can be hooked into exists
question is heuristics, legality, and whether it fits into the PE domain or not
Olli: it probably fits into PE as you should be able to use it with all pointers...but if not all OSs support, could/should browsers support it themselves (sending coords to their internal compositor, improving latency/performance a bit)
is that doable in chrome
Navid: forgot to mention that, already discussed with team, and it would also work/improve performance
worth shipping, EVEN if it was only platform native on Win and other platforms do it in browser?
Olli: still need to iron out issues like cross-origin iframes etc
Patrick: wondering if it's not scope creep to cram this into Pointer Events spec itself - thinking for instance PointerLock spec which is separate
Navid: concern also with exclusions/IP, so it might prevent us from doing it as part of PE
but it should build on top of PE
<plh> --> https://www.w3.org/2018/12/pointerevents-charter.html#out-of-scope Out of Scope
Patrick: agree, might be worth making extension/incubating
further updates from TPAC?
[Olli mentions pen action idea that was discussed]
Navid: event pointertype CSS definition (?) expanding touch-action to have support per pointer type. will file something on mailing list/gh
Microsoft will write an explainer for it
Mustaq told me that CSS folks wouldn't like this to be part of CSS, as these are not about rendering but targetting of events
Patrick: are we happy to go ahead with merge, and then go for First Public Working Draft stage
Navid: we have some aspects that are handwavy in current text in extension. are we happy with it for now, or do we want to make it more algorithmic like similar specs, rewrite portions to formally and precisely do it
Olli: that would all depend on Gary's UI event rewrite
Navid: when PE started, it was right before UI events stuff. we started having UI events relying on us in terms of dispatch algorithm
one thing we can do with FPWD is be ok with what we have now and hope for best/tweak
plh: do we have any test for this?
Navid: yes
plh: then i say merge it
Olli: +1
Navid: going to send PR and have Webkit folks also look at it. deadline of about 1 month?
plh: yes and then we can publish
FPWD
... when you do merge, can you also move test as
appropriate?
Navid: yes, will sync
PAtrick: this is mostly a wrist-slap for myself as i promised i'd do a basic PR, but not got around to it. hope to have for next meeting
<NavidZ_> https://github.com/w3c/pointerevents/pull/300
Navid: i had this pull request...
that's current proposal, it seems that people are ok with it?
Olli: commented on it but not reviewed again
Navid: briefly discussed with Gary
will be dealt with in UI events
bigger undertaking than just PE
suggestion: don't touch it for now
Olli: was also mentioning to Gary, and it's UI events issue about better algorithmic spec
do we have a matching UI-events issue? if so we could just link
Navid: don't see an issue, want to create one?
Olli: i'll create one
Patrick: and we leave ours open to see what comes back
rrsagent generate minutes
<smaug> ah, I'll be in Toronto in two weeks. But the time should be fine
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 plh NavidZ Olli_Pettay Found Scribe: patrick_h_lauke Inferring ScribeNick: patrick_h_lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019OctDec/0001.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]