Meeting minutes
Recharter w3c/strategy#515
Patrick: all wording changes to the charter that we discussed/were raised have been done. last outstanding piece is a rough prototypical "here's the list of events for gestures we want to cover"
[some discussion on which types of events we want - rotate/zoom and possibly swipe, or is swipe the same-ish - moving centroid]
ACTION: Patrick to draft gesture event outline for next meeting
Follow-up from UI Events meeting https://docs.google.com/document/d/1iRFgqtReyomoCwZFEdRUdoW1ManD5t656CVUGJm7Xos/
plh: i have a PR for UI events w3c/
plh: still need to figure out pointerlock (trying to get webapps to move that out)
plh: we'll keep linking to the external algos. once moved, the link will update
plh: some like focusable area and click-focusable defined in HTML,but they're not exporting them. we can either link, or ask HTML spec to export
plh: looked a bit at default action idea
plh: if you look at DOM spec it handles the idea of default action already. just that it calls it activation behaviour
olli: that's only for click
plh: there's different types ... activation behaviour, and LEGACY activation behaviour. trusted behaviour, cancelled not set to true.
plh: all we need to do is define what the legacy activation behaviours are for click, and what the activation behaviours are for all other cases
plh: am i correct? somebody double-check my understanding
<mustaq> https://
plh: if i understand the dispatch behaviour, that's covered. legacy activation for click, and the others are for other events
mustaq: in the default action of keydown it links to the activation behaviour
"Varies: beforeinput and input events; launch text composition system; blur and focus events; keypress event (if supported); activation behavior; other event"
plh: i believe one way out then is not to talk about default action, but talk about activation behaviour
olli: but activation behaviour is specific to click. it assumes trusted events...
rob: i believe it covers just things like click. doesn't handle text selection, or scrolling, or similar
plh: then way forward may be to ask for a hook to handle these other cases, and we hook into that, rather than patching the dispatch algo ourselves
plh: we get dispatch algo updated to take into account those default actions. or we clarify that these are actions after the dispatch
rob: the action does happen in between events though...
olli: but after the relevant event was sent...
rob: yes, but not after all events...so there's some specific order/timing
rob: no strong feeling if it needs to be in the dispatch, or after the dispatch...
plh: assuming it's trusted, cancelable flag set to false, it then happens after dispatch...
plh: i'll see what that looks like, but if not we need to modify dispatch...
plh: hit-test algo is only used by mouse events. i moved it to PE, but then realised it conflicts with our glossary. removed our glossary...
rob: it should all be the same thing. think for longest time it didn't exist other than SVG
plh: DOMActivate - as part of legacy bits, the DOMActivate is still present in ui events. but you're not supposed to use that anymore in preference of click. do we want it, or leave it? legacy section
olli: should probably go to HTML...
Patrick: yeah from memory this is the "click is not device agnostic as a term, let's invent something new" but that was too late. for history, still good to have that somewhere. probably HTML
plh: so somebody should make a PR/proposal to HTML spec. if you know a contact with an editor at HTML spec, ask them...
olli: not seeing any WPTs for DOMActivate...
plh: i'll bring that up to the next UI events meeting next month
plh: beyond that i think i'm done with the PR
plh: we'll wait for next UI events meeting to merge
plh: WPTs ... any idea what best approach might be? if we move them, would things break?
mustaq: i'm worried about links to tests breaking
rob: we could leave behind a text file pointing to the new location? i think it's nice to have the structure of WPT match the specs
mustaq: should we wait for WPT move until things settle down?
rob: spec move doesn't affect WPT. so what do we need to wait for?
mustaq: should we wait until the ui events part is merged into PE and baked in
plh: going to make PR against WPT. then we know we have all components (spec change, WPT), then we can decide on sequencing
plh: other consideration is MDN, as they link to tests and specs
mustaq: also caniuse etc
plh: need to make a list of what will be affected. like... for MDN, does it repoint automatically, or does it need a PR
rob: we know what the anchor links are...maybe we can add in a mention about the move and point there
olli: and that needs to only be a temporary thing
plh: making a tasklist on the PR
olli: caniuse seems to link to MDN
mustaq: there's links to actual specs
mustaq: there's a webDX community group. maybe reach out to them too
<flackr> mdn/
rob: two files in web-features that will need updating. just a one-line change
<flackr> https://
plh: link those from the PR, if easy enough i can make a PR for those too
mustaq: any other repos in web-platform-dx that might be relevant/need updates?
<mustaq> https://
rob: nothing seems to come up from a search
mustaq: question about the larger picture - how will the PE spec itself "work" structure wise / logically
olli: maybe we should add a note warning that things are still in progress
rob: keep sections, but note that it's WIP
<mustaq> +1, a note for each top level section make sense.
Patrick: was also thinking that we may need an update to the prose at the start of the spec, to explain why all of a sudden we also have mouse and wheel stuff
WPTs
mustaq: i looked into the non-standard tests ... we essentially we don't the non-standard part inthe stable part ofthe spec. will do a PR
plh: still need to do implementation report, taking results and then filtering things we don't cover in the spec
mustaq: moving the non-standard tests that are in tentative, and ignore the touch-action ones for values that are not in level 3, that should be complete