14:58:39 <RRSAgent> RRSAgent has joined #pointerevents
14:58:44 <RRSAgent> logging to https://www.w3.org/2024/07/31-pointerevents-irc
14:59:50 <Patrick_H_Lauke> Meeting: PEWG
15:00:00 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:00:07 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/16b7312b-55ac-4645-8312-0d8103f75519/20240731T110000/
15:00:15 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:00:23 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
15:01:06 <Patrick_H_Lauke> present+
15:01:08 <Patrick_H_Lauke> present+ smaug
15:01:12 <Patrick_H_Lauke> present+ mustaq
15:01:28 <flackr> flackr has joined #pointerevents
15:02:30 <Patrick_H_Lauke> present+ flackr
15:04:05 <Patrick_H_Lauke> Topic: ‘Logical’ values for the ‘touch-action’ property https://github.com/w3c/pointerevents/issues/505
15:04:54 <Patrick_H_Lauke> pull request https://github.com/w3c/pointerevents/pull/496
15:05:21 <Patrick_H_Lauke> Olli: question for us is if it's important for us to have logical values NOW or to wait until after level 3
15:05:30 <Patrick_H_Lauke> Rob: I think it's important to authors
15:05:44 <Patrick_H_Lauke> Olli: is it though? would authors use it?
15:06:18 <Patrick_H_Lauke> Olli: also because it's already easy to do things with `dir` selectors...
15:06:38 <Patrick_H_Lauke> Rob: the fact that CSS does already provide other logical values, it would make sense...
15:06:58 <Patrick_H_Lauke> Olli: not against it, just wondering about how important it is
15:07:08 <Patrick_H_Lauke> Rob: does `overflow` have logical values?
15:07:13 <Patrick_H_Lauke> Patrick: don't THINK so
15:07:41 <Patrick_H_Lauke> Rob: in which case, as the touch-action may work in tandem with overflow, there might be an argument to hold off for now
15:09:09 <flackr> https://github.com/w3c/csswg-drafts/issues/2000
15:10:23 <Patrick_H_Lauke> Rob: indeed it seems that overflow DOES have logical support (`overflow-block`, `overflow-inline`)
15:10:25 <Patrick_H_Lauke> https://drafts.csswg.org/css-overflow-3/
15:10:44 <flackr> https://www.w3.org/TR/css-overflow-3/#overflow-control
15:11:50 <Patrick_H_Lauke> Olli: so it's only in draft, not in a recommendation, so lack of full implementation support is fine
15:12:48 <Patrick_H_Lauke> Olli: going back to logical touch-action, i'm not against it
15:13:12 <Patrick_H_Lauke> Olli: but do we need implementation before we can go to REC
15:13:38 <Patrick_H_Lauke> Patrick: I believe we're ok if we DON'T have an implementation / 3 implementations, but then it can't leave REC? need to check with PLH
15:16:07 <Patrick_H_Lauke> Patrick: so i'm tending to lean more towards leaving this out for Level 3, so we don't end up in a situation where we can never get to REC until we have those 3 implementations now, and tackling this after Level 3 / in living standard
15:16:31 <Patrick_H_Lauke> Olli: we can comment on the issue, also reference the fact that overflow-block/overflow-inline (which are related here) aren't in a stable spec either
15:17:04 <Patrick_H_Lauke> ACTION: answer i18n wide review question about logical values for touch-action, defer until after level 3
15:17:26 <Patrick_H_Lauke> Topic: github branches and multiple levels/versions
15:18:08 <Patrick_H_Lauke> Patrick: Philippe answered question about what to do with multiple versions and branches. Pasting in his suggestion here
15:18:14 <Patrick_H_Lauke> Assuming level3 is at the point where changes are less frequent, here is  how I would do this:
15:18:14 <Patrick_H_Lauke> For GitHub :
15:18:14 <Patrick_H_Lauke> Use 2 branches:
15:18:16 <Patrick_H_Lauke>  - "gh-pages" branch for the next version (Level 4)
15:18:18 <Patrick_H_Lauke>    such that the editor's draft is always the latest thinking from the  Working Group
15:18:20 <Patrick_H_Lauke>  - "level3" branch for the level 3 version.
15:18:22 <Patrick_H_Lauke> A change on the gh-pages branch may need to be backported to the level3  branch.
15:18:24 <Patrick_H_Lauke> We will need a Group decision to publish a first public Working Draft  for level 4 if we want to reflect the gh-pages branch to w3.org/TR .  This can be done as soon as the Group would like (ie independently on  the progress on level 3).
15:18:26 <Patrick_H_Lauke> For level 3 updates on /TR, we could do so manually (ie, tell plh to  publish an update). The Group is in the middle of its wide review before  moving to CR anyway.
15:18:29 <Patrick_H_Lauke> For https://www.w3.org/TR :
15:18:31 <Patrick_H_Lauke> Currently,
15:18:32 <Patrick_H_Lauke> the "latest" version of pointer events is Level 2:
15:18:34 <Patrick_H_Lauke>   https://www.w3.org/TR/pointerevents/latest/
15:18:36 <Patrick_H_Lauke> the "upcoming" version is Level 3:
15:18:39 <Patrick_H_Lauke>   https://www.w3.org/TR/pointerevents/upcoming/
15:18:40 <Patrick_H_Lauke> and the Group chose to show the "latest" version when people go to
15:18:42 <Patrick_H_Lauke>   https://www.w3.org/TR/pointer-events/ .
15:18:44 <Patrick_H_Lauke> Once level 3 is in CR and level 4 gets published, both the latest  version and upcoming links will be updated (to level 3 and level 4  respectively).
15:20:57 <Patrick_H_Lauke> Topic: Multi-pen support and persistent pointerId #353 https://github.com/w3c/pointerevents/issues/353
15:20:57 <Patrick_H_Lauke> Final review of https://github.com/w3c/pointerevents/pull/495 which we'll then merge into the next branch
15:21:31 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/pull/495
15:23:10 <Patrick_H_Lauke> Patrick: do we want to review now, or give you time until next meeting? when we're happy, we can then merge this into the next version's branch (from previous topic)
15:23:14 <smaug> https://wpt.fyi/results/pointerevents/persistentDeviceId?label=master&label=experimental&aligned&q=pointerevents%2Fpersistentdeviceid%2Fget-persistendeviceid-from-pointer-event.tentative.html
15:23:30 <Patrick_H_Lauke> Rob: I reviewed the PR and it's good, not looked at tests
15:23:36 <Patrick_H_Lauke> Mustaq: I can have a look at tests offline
15:23:48 <Patrick_H_Lauke> Olli: I'm surprised by the results (link above)
15:24:40 <Patrick_H_Lauke> Rob: I will note, in the test the assertion seems to be that the persistent device id is equal to zero, so without strict type equality it might allow undefined. not sure.
15:25:18 <smaug> https://searchfox.org/wubkat/source/Source/WebCore/dom/PointerEvent.idl
15:25:19 <Patrick_H_Lauke> Rob: no, there's actually a typecheck. I don't know why safari would be passing that....
15:26:05 <Patrick_H_Lauke> Olli: not quite sure what the test harness is actually saying...
15:26:56 <Patrick_H_Lauke> Olli: in firefox i guess it's about ... using pen maybe? anyway, seems fine. seems it's issues with the testing harness
15:27:55 <Patrick_H_Lauke> Patrick: do we need to fix the harness (if there's problems with it?)
15:28:17 <Patrick_H_Lauke> Olli: no, this should be fine, once implementations are done it should all be fine (?)
15:29:29 <Patrick_H_Lauke> Olli: still weird that it's not available in pointerdown, as that's exactly when i'd want to use it, but...
15:29:33 <Patrick_H_Lauke> Rob: ...hardware...
15:30:04 <Patrick_H_Lauke> Olli: just looking at the diff, seems reasonable for the future branch
15:30:47 <Patrick_H_Lauke> Patrick: so are we ok then if I merge this once i sorted out the branches (from previous topic)?
15:30:51 <Patrick_H_Lauke> Rob: sounds good to me
15:31:05 <Patrick_H_Lauke> ACTION: Patrick to merge the PR into the future/v4 branch once set up
15:31:18 <Patrick_H_Lauke> TOPIC: Triage unlabelled issues https://github.com/w3c/pointerevents/issues
15:32:24 <Patrick_H_Lauke> Patrick: do we want to go through things now, or leave it until next time?
15:32:54 <Patrick_H_Lauke> Mustaq: I'm just commenting on #507 and I think it needs more thought - we still don't know if dblclick should be a pointer event
15:33:00 <Patrick_H_Lauke> Rob: why shouldn't it?
15:33:12 <Patrick_H_Lauke> Mustaq: there's mention of dblclick being a legacy event
15:33:25 <mustaq> https://github.com/w3c/pointerevents/issues/507#issuecomment-2256819617
15:34:15 <Patrick_H_Lauke> Mustaq: I think in issue #100 we did it for click and contextmenu, but not dblclick https://github.com/w3c/pointerevents/issues/100
15:34:42 <smaug> https://github.com/w3c/pointerevents/issues/100#issuecomment-684017528
15:34:53 <Patrick_H_Lauke> Olli: so chrome code was changed after that, and dblclick IS a pointer event?
15:35:23 <Patrick_H_Lauke> Rob: use of dblclick is pretty low, and it shouldn't be too HARD to make it consistent with click and contextmenu?
15:36:11 <Patrick_H_Lauke> Rob: think you said it's the same as click with details count of 2, so shouldn't be that hard to make it same?
15:36:30 <Patrick_H_Lauke> Mustaq: ...it's underspec'd, so do we want to complete this....
15:36:57 <mustaq> "This event type MUST be dispatched after the event type click if a click and double click occur simultaneously, and after the event type mouseup otherwise."
15:37:06 <mustaq> https://w3c.github.io/uievents/#event-type-dblclick
15:37:54 <Patrick_H_Lauke> Mustaq: so I don't know if that means that on some platforms it doesn't send a second click and only a dblclick, or... spec is definitely incomplete/vague here
15:39:10 <Patrick_H_Lauke> Rob: I just think it'd be weird if click and dblclick had different event targets
15:39:21 <Patrick_H_Lauke> Rob: regardless of the vagueness of the ui events spec
15:41:38 <Patrick_H_Lauke> Rob: because with details and count on the click event, it seems reasonable to assume that the second click would be sent as well as dblclick. so if we get click, click, dblclick, it would make sense to have event targeting use the same mechanism
15:42:44 <Patrick_H_Lauke> Mustaq: ... we'll need changes both in pointer events spec and ui events spec
15:43:13 <Patrick_H_Lauke> Patrick: so is this something we can do NOW, or do we defer?
15:43:36 <Patrick_H_Lauke> Mustaq: i'm on the fence. What does Mozilla think?
15:43:47 <Patrick_H_Lauke> Mustaq: do it now, or do it later when we have time
15:44:09 <Patrick_H_Lauke> Olli: unsure if we need to fix it right away. just checking in Chrome, and it's mouse event at the moment as well
15:44:18 <Patrick_H_Lauke> Olli: is it behind a flag?
15:44:36 <Patrick_H_Lauke> Mustaq: i think we had it as pointer event, and then changed it back based on the comment from Navid
15:45:20 <Patrick_H_Lauke> Olli: wonder how much work. ui events needs updating so dblclick is PE...
15:45:43 <Patrick_H_Lauke> Mustaq: then changes in our spec to make it like a click
15:45:57 <Patrick_H_Lauke> Olli: yeah, might be easy to...
15:46:05 <Patrick_H_Lauke> Olli: no strong opinion
15:47:16 <Patrick_H_Lauke> Olli: masayuki linked to this interop issue...
15:48:03 <Patrick_H_Lauke> Mustaq: I commented on that that we don't need to update the click test, dblclick is separate
15:49:33 <Patrick_H_Lauke> Olli: ... can wait for masayuki's comment on that interop issue
15:50:19 <Patrick_H_Lauke> Mustaq: masayuki also mentioned something about bxSlider - if we can find a link about what broke in the past
15:53:16 <Patrick_H_Lauke> Mustaq: want to keep interop 2024 untouched if possible, and i don't think click event test needs to change
15:54:36 <Patrick_H_Lauke> Olli: having a site that broke 6 years ago shouldn't prevent us from doing changes
15:55:07 <Patrick_H_Lauke> Patrick: so ... we try to do it now or defer?
15:56:13 <Patrick_H_Lauke> Mustaq: maybe for #508 we need some tweak, because if masayuki was confused by the wording, it may happen for other developers. should be a simple PR if there's a way to clarify this thing. I couldn't think of a clearer explanation, but maybe somebody else can have a go
15:57:07 <Patrick_H_Lauke> Olli: I'll discuss this with masayuki
15:57:26 <Patrick_H_Lauke> ACTION: Olli to talk to Masayuki and see if simple changes can be made to spec
15:59:57 <Patrick_H_Lauke> Patrick: we're coming up to time, so I'd say for remaining issues, have a look through and at least do an initial "v3" or "future" label so we see what's still left before we can push v3 to the start of the whole REC journey. Catch you all next time.
16:00:05 <Patrick_H_Lauke> RRSAgent, set logs world-visible
16:00:11 <Patrick_H_Lauke> RRSAgent, generate minutes
16:00:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/31-pointerevents-minutes.html Patrick_H_Lauke
16:00:30 <Patrick_H_Lauke> RRSAgent, bye
16:00:30 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2024/07/31-pointerevents-actions.rdf :
16:00:30 <RRSAgent> ACTION: answer i18n wide review question about logical values for touch-action, defer until after level 3 [1]
16:00:30 <RRSAgent>   recorded in https://www.w3.org/2024/07/31-pointerevents-irc#T15-17-04
16:00:30 <RRSAgent> ACTION: Patrick to merge the PR into the future/v4 branch once set up [2]
16:00:30 <RRSAgent>   recorded in https://www.w3.org/2024/07/31-pointerevents-irc#T15-31-05
16:00:30 <RRSAgent> ACTION: Olli to talk to Masayuki and see if simple changes can be made to spec [3]
16:00:30 <RRSAgent>   recorded in https://www.w3.org/2024/07/31-pointerevents-irc#T15-57-26