<scribe> Scribe: Patrick H. Lauke
been a while since we met. let's look at minutes from last time https://www.w3.org/2020/09/30-pointerevents-minutes.html
Liviu: working on this. moving forward with shipping in blink. something missing in HTML spec for "click". had pull request that was merged by Domenic. moving forward now
smaug: do we have wpt tests for this?
Liviu: i have a very simple test for it, yes
smaug: what happened to the pointerType
is it just empty string
Liviu: yes
smaug: and i guess that also happens for keyboard-generated click events
Liviu: yes
Patrick: related to that we have this PR https://github.com/w3c/pointerevents/pull/317
can we/should we merge it now
I see a comment from Olli
smaug: yes i don't know why we need to change the identifier part here (not backwards compatible)
btw what is pointerID when click is triggered by keyboard
?
per spec it should be 0
Patrick: have we got a test anywhere to check this?
smaug: per current spec it should be 0
Patrick: i will investigate minutes from around the time this PR was made and see if i can glean why the requirement for positive identifiers was added. if not, i'd say remove that bit and merge the rest, assuming that part is ok?
smaug: UIevents spec now defines that click etc are pointer events, but does not define what pointerType and pointerId should be
it will always be zero. but is that what we want
Liviu: that was one of the reasons we wanted this feature - so that you can match up the id to the pointer event that generated it
smaug: that is not mentioned in the UIevent spec though, so where is it defined?
Patrick: should that be done in the PE spec or UI spec? or both?
Liviu: the behaviour for id is defined in Navid's PR
<scribe> ACTION: Patrick to check old meeting minutes from March about the change to unique id. if not found, remove that change but merge the rest
https://github.com/w3c/pointerevents/issues?page=1&q=is%3Aissue+is%3Aopen
Patrick: should we close this as ball in CSS WG court?
smaug: yes we can close, doubt we need to add anything to PE spec for this
smaug: closing issue 227 as
well
... on issue 75 last comment from Navid wondering if chrome
changed behavior
Patrick: is this still the test? https://output.jsbin.com/zuwiwep
and what is the expected behaviour that we would want to see?
Firefox and Chrome still behave differently now
Edge (Chromium) unsurprisingly consistent with Chrome
Liviu: there's also a wpt test for this
Patrick: have to admit my brain hasn't wrapped itself around what the problem/edge case is, but: is this a bug in Firefox, or a contentious issue that needs more definition/discussion?
smaug: i think chrome's behavior does make sense. but there's the other issue about lost pointer capture, not sure which is right there
Patrick: worth discussing further on the github issue rather than trying to hash out on the call
<scribe> ACTION: Olli to look at https://github.com/w3c/pointerevents/issues/75 further to discuss issue of lost pointer capture order
Patrick: was going to write a note, but need to understand a bit better first myself
wondering if it's something we want to leave up to user agents, or hard spec/require
or just mentioning as a note as "some UAs may..."
smaug: on previous topic, Chrome is definitely wrong when it fires lostpointercapture - spec is clear it should be immediately after pointerup
Patrick: if you could add to the github issue that'd be good
<scribe> ACTION: Patrick to experiment/read over the issue again and propose a non-normative note in PR - spec already says this, but this would clarify it
Patrick: this should be a non-normative note, will do a PR for that too
<scribe> ACTION: Patrick to write note for issue https://github.com/w3c/pointerevents/issues/292
Patrick: probably another one better suited to discussing directly in github rather than here
smaug: I had question for blink folks about whether they're happy to change their behaviour but that hasn't been answered
Patrick: would be good to decide whether we want to pursue this for v3 or not (i doubt it)
we'll reconvene in two weeks' time. meanwhile, please review the above issues, and any other low-hanging fruit ones that may already be resolved/can be closed, or that are clearly not in scope for v3, and let's try to chip away some more at the outstanding issues.
This is scribe.perl Revision of Date 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 smaug Liviu No ScribeNick specified. Guessing ScribeNick: Patrick_H_Lauke Found Scribe: Patrick H. Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020OctDec/0021.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: olli patrick 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]