Meeting minutes
Reword/expand touch-action definition #349 Think we're close to the finish on this one - would like to see if we can finalise this on the call.
https://
Patrick: [discussion around Olli's comment on "none" being unclear] wondering if we do need to be more explicit there in the definition, since straight after the definition list we have the paragraph about what touch-action does or doesn't cover
Patrick: but we could move that para *before* the definition list, less likely to be missed by a casual reader
Mustaq: yes that sounds like a good idea
https://
Olli: yes, happy for the paragraph to be moved and to keep definition of none short as currently proposed
Patrick: i had further thoughts on this section as well https://
at the start of section 9 https://
[discussion on the first part about unclear intro to section 9]
Mustaq: I can see what you mean now, you mentioned this before. Let's land this PR first and make this a separate PR
Patrick: agreed
Patrick: second concern is whether the second note in https://
Mustaq: this is more related to your other PR
Patrick: yes, just wondering generally if this should be made normative rather than an informative note
Olli: does your other PR (#350) do this already?
Patrick: probably makes sense to look at this thought as part of the other PR
Action: Patrick to move paragraph explaining touch-action does not affect text selection/highlighting, link activation, etc *before* the definition list in section 9.3
Major refactoring: refer to "direct manipulation" rather than "touch" #350
https://
Patrick: not had a chance to look at this in much depth since last time, but one comment
https://
[discussion on using "direct manipulation *for* panning / zooming" to cover the concept better and bridge the gap between the two different views of what "direct manipulation" means (touchscreen-style panning/zooming/touching screen versus the "any GUI with a mouse" view of the term)]
[general agreement that the term like that is better, but concern that the spec itself may get too heavy-handed and difficult to read/understand]
Patrick: what i propose is that for next time, i'll make either a modification to PR 350, or a fresh PR, using this term and keeping it clear. moving "direct manipulation for panning/zooming" into a definition and try to avoid having to define it everywhere
Action: Patrick to either change PR 350 or supersede with a new one, incorporating the "direct manipulation *for* panning/zooming" concept
Click event while a pointer event is captured #75
https://
Patrick: just wanted to get a feel
Olli: surprised by Safari's behavior. was ready to make Gecko behave like Chrome, but now not sure why Safari is doing it differently
Patrick: Safari for scenario 2 behaves like Firefox, so both behave differently from Chrome
Liviu: just tested 2 in Chrome, and grey gets the click
Patrick: I propose that I spend some time documenting current state of Chrome, Firefox, Safari for all 4 scenarios, so we get a better picture of what the current state of play is / where the delta is. This issue was opened 2016, so the whole convo is a bit unwieldy to follow
Action: Patrick to document what current browser behaviors for the 4 tests actually is, to ease further discussion on #75
plh: do we have a test in WPT
mustaq: i think we have a test https://
<mustaq> https://
<liviu> https://
plh: we should have test results, but maybe this is from a time before we had web driver support
mustaq: the test is manual, not an automated test
<mustaq> WPT result: https://
mustaq: actually, scratch that, test is automated
mustaq: so yes we have some issues there
Patrick: so either chromium needs to change (and we redefine what is correct), or gecko/webkit need to change
Olli: also differences in how capture is lost
mustaq: probably best to separate out those two concerns, easier to discuss
<mustaq> I suggest covering "click event target" through this issue...
<mustaq> and file a new issue for ordering of lostpointercapture.
Patrick: suggest closing this issue (from 2016 onwards) as it's a bit unwieldy. supersede it with a fresh issue. Olli do you mind doing that?
Olli: sure
Action: Olli to open new fresh issue for click event target issue once Patrick has documented table of current behaviors
Patrick: AOB?
Liviu: i opened a new issue https://
Mustaq: [explains at high level the issue of what happens/what's the order of events between frames. DOM/UI events spec may not handle this either]
<mustaq> https://
Mustaq: don't think we can solve this in meeting today, but worth considering
<smaug> mustaq: ah, I see, release on move
Patrick: worth iterating over this in github, let's see what where we land for next meeting
Patrick: in meantime, I'll be working/reworking #350, and merge #349 after moving the paragraph before the definition list as discussed