Minutes from PEWG meeting 31 July 2024

Dear all,

the minutes from today's meeting are at 
https://www.w3.org/2024/07/31-pointerevents-minutes.html and copied below:



PEWG
31 July 2024
Agenda: 
https://www.w3.org/events/meetings/16b7312b-55ac-4645-8312-0d8103f75519/20240731T110000/
IRC log: https://www.w3.org/2024/07/31-pointerevents-irc

Attendees
flackr, mustaq, Patrick_H_Lauke, smaug

Chair: Patrick H. Lauke
Scribe: Patrick_H_Lauke


* ‘Logical’ values for the ‘touch-action’ property w3c/pointerevents#505
* github branches and multiple levels/versions
* Multi-pen support and persistent pointerId #353 w3c/pointerevents#353
* Triage unlabelled issues https://github.com/w3c/pointerevents/issues



# ‘Logical’ values for the ‘touch-action’ property w3c/pointerevents#505

pull request w3c/pointerevents#496

Olli: question for us is if it's important for us to have logical values 
NOW or to wait until after level 3

Rob: I think it's important to authors

Olli: is it though? would authors use it?

Olli: also because it's already easy to do things with `dir` selectors...

Rob: the fact that CSS does already provide other logical values, it 
would make sense...

Olli: not against it, just wondering about how important it is

Rob: does `overflow` have logical values?

Patrick: don't THINK so

Rob: in which case, as the touch-action may work in tandem with 
overflow, there might be an argument to hold off for now

<flackr> w3c/csswg-drafts#2000

Rob: indeed it seems that overflow DOES have logical support 
(`overflow-block`, `overflow-inline`)

https://drafts.csswg.org/css-overflow-3/

<flackr> https://www.w3.org/TR/css-overflow-3/#overflow-control

Olli: so it's only in draft, not in a recommendation, so lack of full 
implementation support is fine

Olli: going back to logical touch-action, i'm not against it

Olli: but do we need implementation before we can go to REC

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

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

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

ACTION: answer i18n wide review question about logical values for 
touch-action, defer until after level 3



# github branches and multiple levels/versions

Patrick: Philippe answered question about what to do with multiple 
versions and branches. Pasting in his suggestion here

Assuming level3 is at the point where changes are less frequent, here is 
how I would do this:

For GitHub :

Use 2 branches:

  - "gh-pages" branch for the next version (Level 4)

    such that the editor's draft is always the latest thinking from the 
Working Group

  - "level3" branch for the level 3 version.

A change on the gh-pages branch may need to be backported to the level3 
branch.

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).

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.

For https://www.w3.org/TR :

Currently,

the "latest" version of pointer events is Level 2:

   https://www.w3.org/TR/pointerevents/latest/

the "upcoming" version is Level 3:

   https://www.w3.org/TR/pointerevents/upcoming/

and the Group chose to show the "latest" version when people go to

   https://www.w3.org/TR/pointer-events/ .

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).



# Multi-pen support and persistent pointerId #353 w3c/pointerevents#353
Final review of w3c/pointerevents#495 which we'll then merge into the 
next branch

w3c/pointerevents#495

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)

<smaug> 
https://wpt.fyi/results/pointerevents/persistentDeviceId?label=master&label=experimental&aligned&q=pointerevents%2Fpersistentdeviceid%2Fget-persistendeviceid-from-pointer-event.tentative.html

Rob: I reviewed the PR and it's good, not looked at tests

Mustaq: I can have a look at tests offline

Olli: I'm surprised by the results (link above)

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.

<smaug> 
https://searchfox.org/wubkat/source/Source/WebCore/dom/PointerEvent.idl

Rob: no, there's actually a typecheck. I don't know why safari would be 
passing that....

Olli: not quite sure what the test harness is actually saying...

Olli: in firefox i guess it's about ... using pen maybe? anyway, seems 
fine. seems it's issues with the testing harness

Patrick: do we need to fix the harness (if there's problems with it?)

Olli: no, this should be fine, once implementations are done it should 
all be fine (?)

Olli: still weird that it's not available in pointerdown, as that's 
exactly when i'd want to use it, but...

Rob: ...hardware...

Olli: just looking at the diff, seems reasonable for the future branch

Patrick: so are we ok then if I merge this once i sorted out the 
branches (from previous topic)?

Rob: sounds good to me

ACTION: Patrick to merge the PR into the future/v4 branch once set up



# Triage unlabelled issues https://github.com/w3c/pointerevents/issues

Patrick: do we want to go through things now, or leave it until next time?

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

Rob: why shouldn't it?

Mustaq: there's mention of dblclick being a legacy event

<mustaq> w3c/pointerevents#507 (comment)

Mustaq: I think in issue #100 we did it for click and contextmenu, but 
not dblclick w3c/pointerevents#100

<smaug> w3c/pointerevents#100 (comment)

Olli: so chrome code was changed after that, and dblclick IS a pointer 
event?

Rob: use of dblclick is pretty low, and it shouldn't be too HARD to make 
it consistent with click and contextmenu?

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?

Mustaq: ...it's underspec'd, so do we want to complete this....

<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."

<mustaq> https://w3c.github.io/uievents/#event-type-dblclick

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

Rob: I just think it'd be weird if click and dblclick had different 
event targets

Rob: regardless of the vagueness of the ui events spec

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

Mustaq: ... we'll need changes both in pointer events spec and ui events 
spec

Patrick: so is this something we can do NOW, or do we defer?

Mustaq: i'm on the fence. What does Mozilla think?

Mustaq: do it now, or do it later when we have time

Olli: unsure if we need to fix it right away. just checking in Chrome, 
and it's mouse event at the moment as well

Olli: is it behind a flag?

Mustaq: i think we had it as pointer event, and then changed it back 
based on the comment from Navid

Olli: wonder how much work. ui events needs updating so dblclick is PE...

Mustaq: then changes in our spec to make it like a click

Olli: yeah, might be easy to...

Olli: no strong opinion

Olli: masayuki linked to this interop issue...

Mustaq: I commented on that that we don't need to update the click test, 
dblclick is separate

Olli: ... can wait for masayuki's comment on that interop issue

Mustaq: masayuki also mentioned something about bxSlider - if we can 
find a link about what broke in the past

Mustaq: want to keep interop 2024 untouched if possible, and i don't 
think click event test needs to change

Olli: having a site that broke 6 years ago shouldn't prevent us from 
doing changes

Patrick: so ... we try to do it now or defer?

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

Olli: I'll discuss this with masayuki

ACTION: Olli to talk to Masayuki and see if simple changes can be made 
to spec

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.




-- 
Patrick H. Lauke

* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

Received on Wednesday, 31 July 2024 16:04:05 UTC