[gamepad] Add an event-based input mechanism

2014-10-13 Thread Chad Austin
Just as I mentioned in my previous email to this list, I recently was asked to review the Gamepad API draft specification. My background is games though I've done some scientific computing with alternate input devices too. http://chadaustin.me/2014/10/the-gamepad-api/ I'd like to make a second p

Re: [gamepad] Add an event-based input mechanism

2014-10-13 Thread Florian Bösch
Note that events for axis input can (when wrongly handled) lead to undesirable behavior. For instance, suppose you have a 2-axis input you use to plot a line on screen. If you poll the positions and then draw a line from the last position to the current position, you will get a smooth line. However

Re: [gamepad] Add an event-based input mechanism

2014-10-13 Thread Chad Austin
On Mon, Oct 13, 2014 at 1:06 AM, Florian Bösch wrote: > Note that events for axis input can (when wrongly handled) lead to > undesirable behavior. For instance, suppose you have a 2-axis input you use > to plot a line on screen. If you poll the positions and then draw a line > from the last posit

[Bug 22414] 304 handling

2014-10-13 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22414 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 27033] New: XHR request termination doesn't terminate queued tasks

2014-10-13 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27033 Bug ID: 27033 Summary: XHR request termination doesn't terminate queued tasks Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Domenic Denicola
Good question. Takeshi should weigh in on this too since he has been doing some of the integration work. In general, the idea is for streams, like promises, to be a base primitive which many other specifications create instances of. Since the spec is focused on defining that primitive, it doesn

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Paul Cotton
> old specs that had their own custom stream-ish objects will over time upgrade MSE [1] simply used the "Stream" object directly from the previous W3C WD [2]. Since this object no longer is available in [3], what you do recommend that MSE should do? /paulc [1] http://www.w3.org/TR/2014/CR-me

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Domenic Denicola
From: Paul Cotton [mailto:paul.cot...@microsoft.com] > MSE [1] simply used the "Stream" object directly from the previous W3C WD > [2]. Since this object no longer is available in [3], what you do recommend > that MSE should do? OK, down to the fun stuff :). Here's my take based on some brief

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Paul Cotton
>It depends on to what extent these MSE APIs are shipping and thus >compatibility needs to be preserved. MSE is in CR and there are shipping implementations. >I'd love to work with you or the editors on that I have added public-html-me...@w3.org to this thread. /paulc Sent from my Windows Pho

Re: [gamepad] Allow standard-mapped devices to have extra buttons or axes & allow multiple mappings per device

2014-10-13 Thread Brandon Jones
Re: change #1, with standard gamepad mappings today (at least in Chrome) we map any buttons that don't correspond to the official standard mapping to button[17] and up. This, of course, depends on which buttons are actually visible to the browser (many devices expose buttons that can't be "seen" by

[Bug 13410] XML serialisation incompletely defined.

2014-10-13 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13410 Travis Leithead [MSFT] changed: What|Removed |Added Status|NEW |RESOLVED Resolution|-

Re: [gamepad] Allow standard-mapped devices to have extra buttons or axes & allow multiple mappings per device

2014-10-13 Thread Chad Austin
On Mon, Oct 13, 2014 at 3:55 PM, Brandon Jones wrote: > Re: change #1, with standard gamepad mappings today (at least in Chrome) > we map any buttons that don't correspond to the official standard mapping > to button[17] and up. This, of course, depends on which buttons are > actually visible to