- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 11 Nov 2020 19:59:05 +0000
- To: public-pointer-events@w3.org
Dear all, minutes from today's call are at https://www.w3.org/2020/11/11-pointerevents-minutes.html and also copied below: PEWG 11 Nov 2020 Agenda https://lists.w3.org/Archives/Public/public-pointer-events/2020OctDec/0021.html Attendees Present Patrick_H_Lauke, smaug, Liviu Regrets Chair Patrick H. Lauke Scribe Patrick H. Lauke * Should "click", "dblclick" and "contextmenu" events be PointerEvents? https://github.com/w3c/pointerevents/issues/100 (as I note there seems to have been some movement on the related * Standardize CSS pseudoclass behavior for touch https://github.com/w3c/pointerevents/issues/123 * Click event while a pointer event is captured https://github.com/w3c/pointerevents/issues/75 * touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 * Expand note about `click` / `contextmenu` https://github.com/w3c/pointerevents/issues/292 * Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 * touch-action doesn't allow for press-hold-drag UX https://github.com/w3c/pointerevents/issues/178 been a while since we met. let's look at minutes from last time https://www.w3.org/2020/09/30-pointerevents-minutes.html Should "click", "dblclick" and "contextmenu" events be PointerEvents? https://github.com/w3c/pointerevents/issues/100 (as I note there seems to have been some movement on the related 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 Standardize CSS pseudoclass behavior for touch https://github.com/w3c/pointerevents/issues/123 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 Click event while a pointer event is captured https://github.com/w3c/pointerevents/issues/75 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 <Liviu> https://wpt.fyi/results/pointerevents/pointerevent_click_during_capture.html?label=experimental&label=master&aligned 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 touch-action and scrolling directional lock https://github.com/w3c/pointerevents/issues/303 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 Expand note about `click` / `contextmenu` https://github.com/w3c/pointerevents/issues/292 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 Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers https://github.com/w3c/pointerevents/issues/285 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 touch-action doesn't allow for press-hold-drag UX https://github.com/w3c/pointerevents/issues/178 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. Summary of Action Items [NEW] ACTION: Olli to look at https://github.com/w3c/pointerevents/issues/75 further to discuss issue of lost pointer capture order [NEW] 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 [NEW] 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 [NEW] ACTION: Patrick to write note for issue https://github.com/w3c/pointerevents/issues/292 -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 11 November 2020 19:59:20 UTC