<scribe> Scribe: patrick_h_lauke
<smaug> am I the only one on the call?
<smaug> nope
here now :)
https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0064.html
<NavidZ_> the first item is
<NavidZ_> https://github.com/w3c/pointerevents/issues/100
<NavidZ_> Should "click", "dblclick" and "contextmenu" events be PointerEvents?
Bo: outstanding item was what are
use cases. posted use cases we had in edge, differentiate user
experience for things like select control so depending on how
it's opened (mouse/touch) it displays it different (spaced
differently)
... also found article by Chris Wilson from HTML5Rocks / UI
practices
hover-behaviors/click-behaviors
different user experience by pointer type. developers ask questions about it. making actual click etc pointer event would avoid authors having to hack this themselves by listening to pointerdown
counter argument: behavior in edge (for the select spacing) triggered on pointerdown rather than click
would not be difficult for users today to track pointerType when PE come in, and remember that for the click
motivation in short: want to differentiate UX based on pointer type
next steps?
Navid: compat risk of changing existing events
wonder how we would treat other events like drag events, mouse events themselves
pointerType and pointerId only perhaps, as others would just be zero/default?
for drag there were also problems
Olli: this is the bug https://github.com/w3c/pointerevents/issues/106
even riskier and trickier, make drag events inherit pointer events which inherit mouse events
click is also dispatched for keyboard, don't know what edge uses for pointerType in that case
Navid: what would the pointerType of a click be if triggered by mouse
Patrick: "click" is treated a bit like generic "activate"
and keyboard wouldn't make sense to have a faked pointerType
Mustaq: question about the spacing/select use case - should we not use CSS MQ interaction queries?
Patrick: weary of that, as they use whatever brower/OS consider the "primary" input. should really go by what user ACTUALLY is using
Mustaq: ok, use cases seem valid then
Bo: what would compat risk be to add pointerType field to click, doubleclick, etc events
would problem be authors having defined a custom property that would clash? enumerating properties?
Navid: compat risk should be minimal
but changing the whole type and hierarchy of events will be compat risk for sure
Mustaq: and adding new field to click event seems bad because it's not a pointer
Navid: to clarify, we want to add pointerType to the Mouse Events definition
Olli: would make it simpler to fix drag event issue as it inherits mouse event stuff already
Navid: need to check if it's possible to have pointerType in both Mouse Event and Pointer Event model
might need to change where this is defined?
Olli: do we want to call it something else? and do we want/need to decide what keyboard should generate in terms of pointerType? should it be called inputType?
Patrick: i think that would go outside of our remit/scope to define what keyboard does/doesn't
Bo: original idea was that PE was going to replace mouse events. not sure if that's still the view in the larger PEWG
so expanding the definition of mouse events seems to go counter to that
Navid: i share the same idea, but can't see mouse events disappearing. and yes, adding/enhancing mouse events will go against this
Bo: so should we leave click etc alone and wait? should we try to upgrade events like drag, making it inherit from PE, and demonstrate it's safe?
Navid: making click, doubleclick etc actual PE would help towards our ambition/goal
Mustaq: we also have issue of fractional coordinates in PE vs integer coords for mouse events
Navid: do we have data on any
breakages?
... so upgrading/changing click, doubleclick etc to PE may
cause issues as coords then go fractional
... we could try to just tackle click, doubleclick, contextmenu
and leave mousemove etc alone. could be less breaking (with
things like fractional coords)
Bo: I can imagine breaking changes just for apps that present/show coords, so you may now get overflow because of the fractional. my hunch would be breaking change with real compat impact, but have no data
Mustaq: ... we could try to just change click to use fractional in canary
Navid: not just about coords though, it's about making it click a full PE with all the other attributes, AND fractional coords
maybe we should ship and try and see what breaks, suspecting it might be a small percentage
Olli: but what are the benefits? the most useful is just the pointerType / inputType
doing the full "make click a PE" feels very risky for no extra gain
Mustaq: only useful things for use cases mentioned is pointerType
no use case for pointerId
Olli: for JS dev point of view won't matter, they won't look at prototype chain
Bo: think it helps us keep model, PE superset
could be future scenarios where things like pressure on a mouse may also be there
but doesn't help the case of seeing PE as the future to backfill mouse events
i think i hear everybody saying we should use PE and see what the actual compat risk is
Olli: seems minimal gain for too big potential for breaking sites
Navid: to gauge compat risk best way is to enable the change in chrome canary/dev and see what comes back
Mustaq: not sure if we get enough feedback/use though on those
Navid: ...at some point we need to accept some kind of breakage...
extra info on click seems to be useful, even if minimal
enough incentive for us to go and experiment
Patrick: maybe the larger question of should click, doubleclick, contextmenu even be mouse events? it's historical, but should really be "activate" for instance, as they get fired by keyboard too
Navid: could see at TPAC the input events group
Bo: jQuery relies on click being a mouse event, so would break
Navid: if we were to switch click etc to PE, and assuming we can ensure no compat problems, what would we do for keyboard?
[discussion about activation with a keyboard (enter, space, context menu button) not being a fake mouse event, but actually firing things directly in browser based on where the keyboard focus is]
Bo: so where does that leave us, seems it doesn't seem appropriate treating click as a full PE, but perhaps look at inputType backfilled into click as a more generic activation event
Olli: ...and we're not the people who can decide to add things to mouse events or click, we need to speak to UIEvents folks
Bo: can we decide between "click as PE" or "go talk to UIEvent folks"
Navid: did we decide if click as PE what happens with pointerType to keyboard activation?
Patrick: i'd be good with leaving pointerType empty on keyboard, instead of inventing our own for keyboard OR pretending it's a mouse when it isn't. same for future when activating via voice or similar, we don't want to invent these...
Mustaq: can we just try moving click to UIEvent?
Olli: need coordinates
Navid: also modifier keys etc. so can't just move it higher
Either move click down hierarchy (making it a PE) or adding more properties like pointerType to mouse events or whatever
in all cases we need to speak to UIEvents folks
should we just try though to see what happens to inform our decision
scribe: setting pointerType to nothing for anything other than mouse/pen/touch works for now
Mustaq: so what kind of experiment?
Navid: can land behind a flag (experimental web plat features) and see if we get bugs
Mustaq: so what are we trying?
Navid: making click, doubleclick, contextmenu a PE and see what happens (behind the flag)
Mustaq: we'll have to tweak our tests
that expect integer coordinates
Navid: let's be aggressive, set pointerType to null for things like kbd, and see what happens
Patrick: do we want to talk to UIEvents folks already in parallel, or wait until we get data back from this experiment?
Navid: can bring up with them already, but likely having data will be helpful to inform issue / face to face at TPAC
Patrick: who wants to talk to UIEvents folks then?
Navid: I can do that
Patrick: time check - 4 minutes to the hour. Still ok to reconvene in 2 weeks time, or need a call earlier?
Navid: seems 2 week cadence is fine, this topic was quite a chunky one
Patrick: and lastly, do we want to proceed, in a branch perhaps, to merge PE extension to PE v2 to see what the PE v3 will look like once they're merged?
Navid: waiting for TAG review to complete. should we do that now or wait?
Patrick: probably makes sense
then to wait for tag review, THEN merge the thing in a branch,
and then check what the process is with Philippe (if we simply
overwrite the gh-pages, or if it needs to first get changed in
metadata etc)
... 2 minutes to the hour, so let's adjurn. Back in two
weeks.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: patrick_h_lauke Olli_Pettay Navid_Zolghadr Bo_Cupp Mustaq_Ahmed plh_ Found Scribe: patrick_h_lauke Inferring ScribeNick: patrick_h_lauke WARNING: No "Topic:" lines found. Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2019AprJun/0064.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]