Re: Pointer Events WG call 12 June 2019

Thank you all for attending. Minutes from today's call at and copied below:

12 Jun 2019

patrick_h_lauke, Olli_Pettay, Navid_Zolghadr, Bo_Cupp, Mustaq_Ahmed, plh_
Summary of Action Items
Summary of Resolutions
<scribe> Scribe: patrick_h_lauke

<smaug> am I the only one on the call?

<smaug> nope

here now :)

<NavidZ_> the first item is


<NavidZ_> Should "click", "dblclick" and "contextmenu" events be 

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


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 

pointerType and pointerId only perhaps, as others would just be 

for drag there were also problems

Olli: this is the bug

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 

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 

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 

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

Patrick H. Lauke | |
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 12 June 2019 16:08:24 UTC