Meeting minutes
‘Logical’ values for the ‘touch-action’ property w3c/pointerevents#505
pull request w3c/
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/
Rob: indeed it seems that overflow DOES have logical support (`overflow-block`, `overflow-inline`)
https://
<flackr> https://
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://
Currently,
the "latest" version of pointer events is Level 2:
https://
the "upcoming" version is Level 3:
https://
and the Group chose to show the "latest" version when people go to
https://
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/
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)
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://
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/
Mustaq: I think in issue #100 we did it for click and contextmenu, but not dblclick w3c/
<smaug> w3c/
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://
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.