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

2014-10-13 Thread Chad Austin
Hi all,

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 suggest two simple changes to the Gamepad API.  In tandem,
these APIs would allow applications to have automatic compatibility with a
broader range of devices.

The changes are:

1. Allow standard-mapped devices to have extra buttons or axes
2. Add support for multiple standard mappings per device.

Together, these changes would allow a simple application that only needs a
d-pad and a few buttons to work automatically with a Wiimote, XInput
device, and a racing wheel (many racing wheels have d-pads on them).

Even without the proposal #2, proposal #1 would allow optional access to
extra capabilities on a device without having to sacrifice the standard
mapping.

This feels noncontroversial to me because mappings only assign meaning to
otherwise neutral indices in the buttons[] and axes[] arrays.  For a given
device, there can be many such meanings.

-- 
Chad Austin
http://chadaustin.me


[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 proposed change to the gamepad API, an
event-based mechanism for receiving button and axis changes.

The full rationale is explained in the linked article, but the summary is:

1) an event-based API entirely avoids the issue of missed button presses
2) event-based APIs don't require non-animating web pages to use
requestAnimationFrame just to poll gamepad state
3) an event-based API could (and should!) give access to high-precision
event timing information for use in gesture recognition and scientific
computing
4) event-based APIs can reduce processing latency when a button changes
state rapidly in low-frame-rate situations

-- 
Chad Austin
http://chadaustin.me


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 if you receive events for axes, each arriving separately, and use
each to plot a line, you will get a stepped/stairs line.

If nothing but an event based mechanism is present, this would force an
author to catch all axes events and collate them when no more events are
queued. That'd require knowing when are no more events coming, which
cannot be done in a callback based mechanism (as the event queue can't be
queried).

It's conceivable that some use-cases of buttons can run into similar
scenarios (combos and whatnot). Although in these cases, a developer could
probably keep track of the pressed buttons themselves. However, this means
that not only button presses have to be provided, but also button releases,
such that combos could be reliably detected by the developer.

On Mon, Oct 13, 2014 at 9:03 AM, Chad Austin caus...@gmail.com wrote:

 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 proposed change to the gamepad API, an
 event-based mechanism for receiving button and axis changes.

 The full rationale is explained in the linked article, but the summary is:

 1) an event-based API entirely avoids the issue of missed button presses
 2) event-based APIs don't require non-animating web pages to use
 requestAnimationFrame just to poll gamepad state
 3) an event-based API could (and should!) give access to high-precision
 event timing information for use in gesture recognition and scientific
 computing
 4) event-based APIs can reduce processing latency when a button changes
 state rapidly in low-frame-rate situations

 --
 Chad Austin
 http://chadaustin.me



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 pya...@gmail.com 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 position to the current position, you will get a smooth line.
 However if you receive events for axes, each arriving separately, and use
 each to plot a line, you will get a stepped/stairs line.

 If nothing but an event based mechanism is present, this would force an
 author to catch all axes events and collate them when no more events are
 queued. That'd require knowing when are no more events coming, which
 cannot be done in a callback based mechanism (as the event queue can't be
 queried).


You are absolutely correct, and I did not necessarily mean gamepad events
should look like onmousemove or onkeydown.

I was imagining an event more like device has new data, after which a
non-empty list of events would be available from the device.  Presumably,
events in said list can be coalesced to fit within a fixed buffer size if
necessary.

On the specific use case of drawing a smooth line from rough axis input, an
appropriate smoothing algorithm should not rely on polling frequency --
especially requestAnimationFrame frequency -- but instead should generate
the smooth curve (or sequence of line segments or whatever) from
high-resolution event timing information if possible.  Of course, this is
where the discussion starts to approach the intersection of how humans
perceive input and output, and why mice are sampled at hundreds of Hz
rather than the 60 Hz of requestAnimationFrame.

It's conceivable that some use-cases of buttons can run into similar
 scenarios (combos and whatnot). Although in these cases, a developer could
 probably keep track of the pressed buttons themselves. However, this means
 that not only button presses have to be provided, but also button releases,
 such that combos could be reliably detected by the developer.


Yes, definitely.  Button up is as important as button down.


[Bug 22414] 304 handling

2014-10-13 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22414

Anne ann...@annevk.nl changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Anne ann...@annevk.nl ---
https://github.com/slightlyoff/ServiceWorker/issues/412

Closing this in favor of the GitHub issues. It's mostly fixed now anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[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
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: manishea...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

https://xhr.spec.whatwg.org/

When a request is terminated via `abort()` or the timeout, the fetch algorithm
is the only thing that is terminated[1]


However, there's no indication that we need to terminate existing queued up
tasks for the XHR object.

For example, the following can happen:

 - Initialiaze an XHR object, call send()
 - On readystatechange to 2 or 3, in the event handler, perform a long
computation
- In the meantime, the fetch algorithm continues to fetch, and pushes
fetch-related events (eg process response body/process response end of
file) to the DOM task queue.
 - abort() is called once the computation finishes. This aborts the fetch
algorithm, but does *not* remove already-queued events
 - After calling abort(), try to initialize and send a new request with the
same XHR object
 - The queued up tasks from the previous request will now be received by the
XHR object assuming they are for the new request, and we'll have some sort of
frankenresponse.

The w3 spec[2] explicitly mentions that tasks in the queue for the XHR object
should be aborted. I'm not certain if this includes the currently running task
-- if, for example, the user calls abort() followed by a new open() and send()
in the onprogress handler, should the onload/onloadend handlers be called for
the previous request? Probably not -- but this involves checking for an abort
on each step of the send(), which seems icky.

I guess the WHATWG spec needs to be updated to terminate more than just the
fetch algorithm.

 [1]: https://xhr.spec.whatwg.org/#terminate-the-request
 [2]: http://www.w3.org/TR/XMLHttpRequest2/#the-abort-method

-- 
You are receiving this mail because:
You are on the CC list for the bug.



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't include an informative list of specs 
that could potentially use it; we left that for non-spec material. But in 
general the way we envision this working is much like with promises: new specs 
that include streaming data will reach around for the right primitive, and find 
streams; old specs that had their own custom stream-ish objects will over time 
upgrade; and all the while, developers will be prototyping and creating their 
own streams (some of which might wrap existing APIs) using the stream 
constructors. We as editors will be helping reach out and guide those efforts, 
as we've done with promises. Currently there are efforts ongoing with Fetch 
(XHR replacement) and Web Audio as the trailblazers, with more certainly to 
come.

Hope that helps,
-Domenic

-Original Message-
From: Paul Cotton [mailto:paul.cot...@microsoft.com] 
Sent: Thursday, October 9, 2014 19:04
To: Domenic Denicola
Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

The previous W3C WD [1] identified a large number of specifications that were 
stream producers and consumers.  Is there any kind of mapping of the interfaces 
in the previous W3C WD to your recent specification to give all of those other 
specifications some idea of how to change to align with the new Streams 
specification?

/paulc
HTML WG co-chair

[1] http://www.w3.org/TR/2013/WD-streams-api-20131105/#producers-consumers

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-Original Message-
From: Domenic Denicola [mailto:dome...@domenicdenicola.com] 
Sent: Thursday, October 09, 2014 4:24 PM
To: Paul Cotton
Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

From: Paul Cotton [mailto:paul.cot...@microsoft.com] 

 Was this Aug goal achieved? 

Yes: https://streams.spec.whatwg.org/



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-media-source-20140717/#sourcebuffer-stream-append-loop
 
[2] http://www.w3.org/TR/2013/WD-streams-api-20131105
[3] https://streams.spec.whatwg.org/ 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-Original Message-
From: Domenic Denicola [mailto:dome...@domenicdenicola.com] 
Sent: Monday, October 13, 2014 2:40 PM
To: Paul Cotton
Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

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't include an informative list of specs 
that could potentially use it; we left that for non-spec material. But in 
general the way we envision this working is much like with promises: new specs 
that include streaming data will reach around for the right primitive, and find 
streams; old specs that had their own custom stream-ish objects will over time 
upgrade; and all the while, developers will be prototyping and creating their 
own streams (some of which might wrap existing APIs) using the stream 
constructors. We as editors will be helping reach out and guide those efforts, 
as we've done with promises. Currently there are efforts ongoing with Fetch 
(XHR replacement) and Web Audio as the trailblazers, with more certainly to 
come.

Hope that helps,
-Domenic

-Original Message-
From: Paul Cotton [mailto:paul.cot...@microsoft.com] 
Sent: Thursday, October 9, 2014 19:04
To: Domenic Denicola
Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

The previous W3C WD [1] identified a large number of specifications that were 
stream producers and consumers.  Is there any kind of mapping of the interfaces 
in the previous W3C WD to your recent specification to give all of those other 
specifications some idea of how to change to align with the new Streams 
specification?

/paulc
HTML WG co-chair

[1] http://www.w3.org/TR/2013/WD-streams-api-20131105/#producers-consumers

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-Original Message-
From: Domenic Denicola [mailto:dome...@domenicdenicola.com] 
Sent: Thursday, October 09, 2014 4:24 PM
To: Paul Cotton
Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

From: Paul Cotton [mailto:paul.cot...@microsoft.com] 

 Was this Aug goal achieved? 

Yes: https://streams.spec.whatwg.org/



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 
investigation...

It depends on to what extent these MSE APIs are shipping and thus compatibility 
needs to be preserved. If they are shipping, something similar to appendStream 
seems OK: change it to take a ReadableStream and you'll be fine.

However, BufferSource is basically a custom WritableStream instance, with many 
parallels I can outline if necessary. So ideally the related MSE APIs would be 
redesigned to either use a WritableStream directly, or to subclass it. That 
would be more idiomatic in how the streams ecosystem works, and in general 
would allow more compositional scenarios through the usual mechanisms (so that 
e.g. people could integrate the BufferSource writable stream into a generic 
stream pipeline, instead of special-casing how they handle it). I'd love to 
work with you or the editors on that, if there are no compat-constraints 
preventing it.


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 Phone

From: Domenic Denicola
Sent: 13/10/2014 3:04 PM
To: Paul Cotton; Takeshi Yoshino
Cc: public-webapps; Arthur Barstow; Feras Moussa
Subject: RE: [streams-api] Seeking status of the Streams API spec

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 
investigation...

It depends on to what extent these MSE APIs are shipping and thus compatibility 
needs to be preserved. If they are shipping, something similar to appendStream 
seems OK: change it to take a ReadableStream and you'll be fine.

However, BufferSource is basically a custom WritableStream instance, with many 
parallels I can outline if necessary. So ideally the related MSE APIs would be 
redesigned to either use a WritableStream directly, or to subclass it. That 
would be more idiomatic in how the streams ecosystem works, and in general 
would allow more compositional scenarios through the usual mechanisms (so that 
e.g. people could integrate the BufferSource writable stream into a generic 
stream pipeline, instead of special-casing how they handle it). I'd love to 
work with you or the editors on that, if there are no compat-constraints 
preventing it.


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
normal applications, like the home button on Xbox controllers). A good
example is the Touchpad on the PS4 controller. We can't see actual touch
inputs without writing a custom driver, but we detect clicks on the
touchpad and report them as button[17]. The same would go for axes, but
I've yet to encounter a standard-looking gamepad that exposed  four axes
worth of usable data. Perhaps the spec should be slightly reworded in this
regard, since it currently states that The standard gamepad has 4 axes,
and up to 17 buttons, which could be read as explicitly disallowing
buttons or axes beyond that.

I'm not very supportive of suggestion #2 since we don't actually HAVE any
other mappings defined (joystick/flightstick would be the next most natural
candidate, I think, but they can vary significantly). If we did, I'm not
sure how you would reasonably stack mappings without breaking an awful
lot of code. The mappings field would have to be either space/comma
delimited (which breaks things) or turned into an array (which breaks
things) or you would expose the same device twice under different mappings
(which is really weird and probably breaks things.) Beyond that, there's no
way that the layouts of two mapping types could every overlay completely
cleanly, and we really shouldn't be claiming that something that looks like
a racing wheel is actually a standard gamepad anyway. I just can't see
how it would work.

--Brandon



On Sun Oct 12 2014 at 11:59:16 PM Chad Austin caus...@gmail.com wrote:

 Hi all,

 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 suggest two simple changes to the Gamepad API.  In tandem,
 these APIs would allow applications to have automatic compatibility with a
 broader range of devices.

 The changes are:

 1. Allow standard-mapped devices to have extra buttons or axes
 2. Add support for multiple standard mappings per device.

 Together, these changes would allow a simple application that only needs a
 d-pad and a few buttons to work automatically with a Wiimote, XInput
 device, and a racing wheel (many racing wheels have d-pads on them).

 Even without the proposal #2, proposal #1 would allow optional access to
 extra capabilities on a device without having to sacrifice the standard
 mapping.

 This feels noncontroversial to me because mappings only assign meaning to
 otherwise neutral indices in the buttons[] and axes[] arrays.  For a given
 device, there can be many such meanings.

 --
 Chad Austin
 http://chadaustin.me



[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] tra...@microsoft.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #21 from Travis Leithead [MSFT] tra...@microsoft.com ---
I'm not sure if David is monitoring this bug anymore. In any case, it looks
like C. Scott Ananian is still interested in seeing this bug through.

C. Scott, please take a look at:
http://www.w3.org/TR/DOM-Parsing/#dfn-concept-xml-serialization-algorithm, step
15. I think it keeps things as close to HTML serializing interop as practically
possible. For other html-namespaced element is preserves begin/end tag
serialization.

Let me know if there's more that you think can be done here. Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



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 bajo...@google.com 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 the browser (many devices expose buttons that can't be
 seen by normal applications, like the home button on Xbox controllers). A
 good example is the Touchpad on the PS4 controller. We can't see actual
 touch inputs without writing a custom driver, but we detect clicks on the
 touchpad and report them as button[17]. The same would go for axes, but
 I've yet to encounter a standard-looking gamepad that exposed  four axes
 worth of usable data. Perhaps the spec should be slightly reworded in this
 regard, since it currently states that The standard gamepad has 4 axes,
 and up to 17 buttons, which could be read as explicitly disallowing
 buttons or axes beyond that.


Great!  Then I agree - the behavior of Chrome then doesn't match the exact
wording of the spec.  The spec should be updated to reflect reality.

I'm not very supportive of suggestion #2 since we don't actually HAVE any
 other mappings defined (joystick/flightstick would be the next most natural
 candidate, I think, but they can vary significantly). If we did, I'm not
 sure how you would reasonably stack mappings without breaking an awful
 lot of code. The mappings field would have to be either space/comma
 delimited (which breaks things) or turned into an array (which breaks
 things) or you would expose the same device twice under different mappings
 (which is really weird and probably breaks things.) Beyond that, there's no
 way that the layouts of two mapping types could every overlay completely
 cleanly, and we really shouldn't be claiming that something that looks like
 a racing wheel is actually a standard gamepad anyway. I just can't see
 how it would work.


What's the status of the gamepad API?  It reads like it's in a draft state,
yet it has some implementations in the wild...  Is it de facto frozen?

Assuming it's not de facto frozen -- and temporarily sidestepping the
problem of maintaining compatibility with existing implementations -- the
issue with the mapping API _as written today_ is that there's only one
standard mapping, meaning that if you plug in any non-XInput-style device
that has a d-pad, you'll need the customer to specify their own bindings.
Your device is nonstandard.  Press left.  Press up.  Press right.  Press
down.  Press OK.

Beyond that, there's no way that the layouts of two mapping types could
 every overlay completely cleanly, and we really shouldn't be claiming that
 something that looks like a racing wheel is actually a standard gamepad
 anyway. I just can't see how it would work.


The concern that two mappings that each specify a directional pad would not
have overlapping button IDs is valid.

Fundamentally, what I'd like is access to a richer form of per-button and
per-axis metadata than is provided by the API today.  The standard
mapping API provided today is rigid and limiting.  However, I don't have
time to come up with a proposal right now - perhaps coming soon.

+Katelyn as she expressed similar concerns.

Thanks,
Chad