- 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