- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 11 May 2016 11:57:49 +0100
- To: public-browser-tools-testing@w3.org
On 09/05/16 17:06, James Graham wrote: > 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>] > } So I have been reading the pointer events spec a little, and I have the outline of a proposal for a better model here. Redefined <ActionSequence> so it has an optional "parameters" attribute that defines device-specific parameters. For pointer actions this would take a "pointerType" attribute with one of the values "mouse", "pen" or "touch". For now "pen" and "touch" would be alike (except that the value would be reflected in the pointer events generated), but future evolution of the standard would likely lead to differences between them to account for the richer featuresets of pens compared to fingers. As an aside, for key actions, I anticipate that the "parameters" attribute would be used in the future to specify the keyboard layout to use for translating characters to key codes. The difference between "mouse" and other pointer types that we would only generate mouse events for the mouse pointer type. This is different to the pointerEvents model where mouse events are generated for any kind of device that is marked as "primary". I suppose we could directly follow that spec here, and add a second parameter to indicate if a device is primary or not, if people feel it's important to be able to generate mouse events from e.g. a touch pointer event. In addition, I believe we should allow the device id to be optional/null, in which case the implementation will generate a uuid for the device, which will be returned from the command (see below). > <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 > } I think that it doesn't make sense to use the active element as an offset for the coordinates in these actions, because one can reasonably move the pointer to a location that can't take tab focus. Therefore I think it's necessary to provide this element explicitly as part of the action. If we allow the element to be missing, there are two options; set the coordinates relative to the last position of the pointer (it is unclear what to do if this is the first action and so the position is unknown), or set the coordinates relative to the viewport. I think I prefer the option to let it be missing and make it possible to set coordinates relative to the viewport. This would allow a mode of operation in which it was possible to avoid implicit scrolling. So far I think the actions parameters don't return anything. That seems suboptimal from the client point of view. I think I would like to return at least the device id for each action sequence, and maybe a device-specific state object indicating e.g. which keys are in a depressed state. Does anyone have specific use cases for the return value of this command?
Received on Wednesday, 11 May 2016 10:58:19 UTC