PEWG -- 12 Jun 2019

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

- DRAFT -

PEWG

12 Jun 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output