- From: James Graham <james@hoppipolla.co.uk>
- Date: Mon, 9 May 2016 17:06:00 +0100
- To: public-browser-tools-testing@w3.org
Summary of my thinking with the protocol at the moment (as much for my reference as anything): <ActionsCommand> { actions: [<ActionSequence>] } <ActionSequence>: { id: String, # Device id type: "key" | "pointer", # Type of actions in this sequence actions: [(<KeyAction>|<PointerAction>)|<GeneralAction>] } <GeneralAction>: { type: "pause", duration: Integer } <KeyAction>: <KeyUpAction> | <KeyDownAction> <KeyUpAction>: { type: "keyUp", value: String # Single character only. } <KeyDownAction>: { type: "keyDown", value: String # Single character only. } <PointerAction>: <PointerUpAction> | <PointerDownAction> | <PointerMoveAction> | <PointerCancelAction> <PointerUpAction>: { type: "pointerUp" button: Integer # Button number } <PointerDownAction>: { type: "pointerDown" button: Integer # Button number } <PointerMoveAction>: { type: "pointerMove" optional x: Integer | Null # Coordinates to move to relative to the # active element. Need an origin member? optional y: Integer | Null } <PointerCancelAction>: <Null> # I have no idea what this does So, what did I miss. I note that this schema works OK for mice where you have to move + click, but perhaps not for other pointing devices where you can poke at random points without moving across the display. I'm not sure how that is modeled in other specs (i.e. the pointer events spec vs ordinary DOM mouse events).
Received on Monday, 9 May 2016 16:06:28 UTC