W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

[gamepad] preventing default/capturing controller

From: Patrick H. Lauke <redux@splintered.co.uk>
Date: Wed, 26 Feb 2014 10:16:02 +0000
Message-ID: <530DBEE2.8030509@splintered.co.uk>
To: public-webapps@w3.org
"Currently, the only way for a gamepad to be used as input would be to 
emulate mouse or keyboard events"

I'm wondering if it's in scope for this spec to also address the 
situation where a UA *does* already do this natively (for instance, IE 
on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad 
firing cursor event.

A few precedents that may be worth looking at:

- Pointer Lock API http://www.w3.org/TR/pointerlock/

- Opera's spatial navigation on TV browsers, which can be 
preventDefault-ed if the website/app wants to handle d-pad input (mapped 
to cursor keys already, mind) on a remote control 
http://dev.opera.com/articles/view/functional-key-handling-in-opera-device-sdk-based-tv-browsers/#prevent-default

- Boxee's (discontinued) API to explicitly switch browser into different 
modes (cursor, keyboard, player) 
http://developer.boxee.tv/JavaScript_API#Browser_Modes

There's an argument that this should be left completely up to the UA, 
and that users should switch the UA into different modes. However, at 
the very least it would be nice then to have a way for a site/app to 
*signal* that it can handle direct gamepad input.

Thoughts?

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 26 February 2014 10:16:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC