- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 6 Nov 2024 17:03:52 +0000
- To: Pointer Events Working Group <public-pointer-events@w3.org>
Dear all, the minutes from today's meeting are at https://www.w3.org/2024/11/06-pointerevents-minutes.html and copied below: PEWG 06 November 2024 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20241106T110000/ IRC log: https://www.w3.org/2024/11/06-pointerevents-irc Attendees: adettenb, flackr1, mustaq, Olga, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick_H_Lauke * Ensure predicted events only use input from the current partition w3c/pointerevents#518 * Limit the precision of floating point event fields w3c/pointerevents#517 * [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 * Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 * Triage unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking # Ensure predicted events only use input from the current partition w3c/pointerevents#518 Patrick: I've now submitted a pull request Patrick: w3c/pointerevents#518 Patrick: w3c/pointerevents#527 Rob: I'm happy with that as is # Limit the precision of floating point event fields w3c/pointerevents#517 Rob: that one still waiting on me ACTION: Rob to draft an initial PR for this # [touch actions] handwriting manipulation type to distinguish panning w3c/pointerevents#516 <mustaq> We have a PR already: w3c/pointerevents#525 Patrick: wanted to check one of my concerns - because of the way touch-action defines what a user agent CAN handle, would creating a new value for handwriting mean that if they already use touch-action, and they hadn't included this new value, it means that any site will suppress handwriting until they update their touch-action definitions Olga: yes that's a shortcoming of the way touch-action works Rob: yes, we can mitigate this partly though if we say that handwriting is implicit/part of "manipulation" for instance mustaq: i started reviewing the pull request, but not completed Rob: we could see if we can gather data - if we implemented this today, how many sites would be affected? (use touch-action, and would implicitly suppress handwriting because they didn't have that value yet to add) Olga: realistically we'll need a few months to gather this data Rob: we should be able to get this data from canary users. they don't need to have a stylus, we can just run a test of "how many fields that would normally be handwriting eligible would not get this because of the defined touch-action in the page") Olli: I also wonder more fundamentally "what does it mean that something is eligible for handwriting" Olli: such as what happens to focus ... if focus moved automatically into a text field if handwriting started near it and is allowed by the touch action Olli: contenteditable, text areas ... many related aspects Olli: may not just be a CSS WG issue mustaq: focus is defined in HTML? Olli: content editing working group may also be affected... Olga: so far we thought this feature would be just hooking into the platform, is there more that needs to be done? Rob: there's aspects, like with scrolling, where "the platform will do something" which is beyond what we can define in the spec Patrick: would certainly be good to add a note to say clearly that the PE spec does not want to define how handwriting works, what happens specifically, as it's OS dependent. but yes mention that there will be considerations about focus potentially moving, input events being fired, but that it's outside of the PE scope itself Olli: info should also be in the explainer Olga: for edge with implemented handwriting as a text input attribute. then published intent to prototype, but it was not accepted. which is why we're now trying to do it via touch-action Rob: I was the one who wasn't in favour of the intent to prototype. i don't know if anybody from editing looked at it. my main concern is that for many of the use cases, it's about authors saying that they want to handle handwriting, but that for that scenario we suggested to authors in the past doing touch-action:none (so that it can be handled by them, rather than scrolling/panning) mustaq: yeah I think this is slightly different though, as it's a special case of IME ... Olga: in terms of next action we'll add use counter to get data, and add information to explainer how it works in different platforms, what happens to focus, and use cases where handwriting detection is not desired Rob: keeping it high level - you start writing, it detects that you're writing, focuses the nearby input, and fires IME events Olga: we'll present it to editing working group, maybe also html working group (as original idea was to use html attribute, so they could give some extra feedback on that approach) Olli: html attribute is slightly more specific/much nicer, compared to CSS which is a bit more handwavy Rob: maybe a hybrid approach of html attribute AND some touch-action hook / make touch-action aware of handwriting <mustaq> https://github.com/whatwg/html/issues for HTML? ACTION: Olga to present to editing working group, html working group, looking at getting usage counter, expand explainer # Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445 Rob: asked if mustaq can pick this one up, not had much time. no update right now ACTION: mustaq to look at outstanding w3c/pointerevents#300 issue # Triage unlabelled issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+-label%3Afuture+-label%3Av3++-label%3Av3-blocking Olli: looked at some of these before meeting. one can probably be closed depending on what masayuki thinks. Olli: DOM integration one is interesting. think our spec is already clear enough (?) Patrick: w3c/pointerevents#513 Patrick: last comment on that from Olli Olli: I should make a PR for that Patrick: do we think it's v3 or future ACTION: Olli to look at w3c/pointerevents#513 and do a PR Patrick: w3c/pointerevents#511 is the one you mentioned earlier about masayuki Olli: would be good to get somebody from Chrome's side to look at this Patrick: leave unlabelled for now until we work out if there's any action on our part? Olli: fine Rob: fine Patrick: w3c/pointerevents#510 Patrick: do we know what this would entail? does it need clarification in spec? Olli: I think it's fine as is, but would be nice to have more tests Patrick: w3c/pointerevents#509 Patrick: same question - do we think this needs further clarification/work in the spec? Olli: again, i think pointermove is a separate event... Rob: yes, completely separate, and has its own hit testing Rob: might be a case where ... we dispatch pointerrawupdate also for final position of pointer, which could be the same sort of event for pointermove... i forget the details, but because the frequency is higher they *could* have different targets... Olli: but it would still be sent somewhere... Rob: similar to question of what happens to click during the up event Olli: different to an extent. this is more about whether pointermove is completely separate Patrick: so do we need to spell this out more explicitly? Rob: i think per spec they are separate events, so shouldn't need clarification? Olli: yes i wasn't sure about what masayuki says about the paragraphs *implying* anything ACTION: Olli to possibly double-check about w3c/pointerevents#509 whether it needs further explicit clarification / check what the "implied" thing is Patrick: will chase up Philippe about w3c/pointerevents#506 just to check Patrick: thank you all, we'll reconvene in 2 weeks' time. in meantime, look after yourselves and your mental health in light of recent world events... Summary of action items: * Rob to draft an initial PR for this * Olga to present to editing working group, html working group, looking at getting usage counter, expand explainer * mustaq to look at outstanding w3c/pointerevents#300 issue * Olli to look at w3c/pointerevents#513 and do a PR * Olli to possibly double-check about w3c/pointerevents#509 whether it needs further explicit clarification / check what the "implied" thing is -- 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, 6 November 2024 17:04:05 UTC