Re: [gamepad] Allow standard-mapped devices to have extra buttons or axes allow multiple mappings per device
Hi, I agree with Chad's suggestions: the spec should be expanded to expose more than the core set of axes buttons, and richer metadata would be extremely useful to developers. I've been using the gamepad API (as shipped in Chrome, at least - I haven't had time to adapt to Firefox's implementation, because I used gamepad.js and it's a broken pile...) for a while now, in a few shipped JSIL-based game ports. My experiences opinions inform the following. I apologize if this is a bit hard to read, by the way - all this crunch time for the game I'm working on has fried my brain a bit. :-) To try and express my PoV on this (previously stated to WG members/participants, but not directly on this list - sorry, too much on my plate to add another workgroup to my subscriptions): I think best-effort mapping to 'standard' layouts is a great idea. I have some objections to how it is done, but it is an improvement over what we had before. My main concern is that the current design for remapping sets us up for a descent into a quagmire that can't easily be fixed. The scenario I anticipate happening: Gamepads only have one standard mapping, supported by the vast majority of available controllers (let's just say 360 pads and dualshock 3/4 controllers, since those put together probably cover at least 90% of the market). If you expand the remapping to all XInput devices, that widens it even further - though this is problematic in a way I will get to later. If there is one standard mapping, and it covers most users, this means the natural path for developers is to only support the standard mapping. They won't add keybinding/button remapping, they won't add support for multiple layouts, they might not even add support for choosing which of your gamepads you want to use. This is not an unrealistic fear: It is the status quo in virtually all console games and in many PC games. In some cases you can rebind by editing .ini files, but that is out of the question for web games since their configuration typically lies in not-user-editable JS on the server or in blobs stored somewhere (localStorage, indexed db, cookies) that are not easily user-editable. This 'developers only support the easiest thing' future is relatively likely and is actually worse than the previous status quo of raw-controllers-only. I think the solution to this is simple: Ensure that there is more than one standard mapping. Find a way to make sure that developers have to do at least a basic amount of effort to handle things correctly. If the simple hack isn't sufficient for wider audiences, they will have an incentive to do a good job. This doesn't have to be a punitive measure - there are diverse controllers out there that people might want to use, from standard gamepads to racing wheels to flight sticks. Something as simple as supporting the additional inputs of the dualshock 3 4 is a good rationale here (they both have gyros accelerometers; the 4 has a touchpad and touchpanel button.) When the common case is slightly more complicated, it forces developers to at least *understand* the breadth of the problem and make rational choices. It also encourages the development of high-quality, userspace JS wrappers/abstraction layers, so fixes improvements can happen in those libraries. I would argue that the success of XInput is not due to its excessive, somewhat-detrimental 'least common denominator' design, but because it aggressively targeted fixed the most common problems with DirectInput. OK, so, there's my rationale for why the current approach to mapping should change. Now to dive in deeper to some other issues I see with the gamepad API. My first objection to the design implementation is that it is based on passive enumeration device acquisition. You have to poll to find out what gamepads there are and interact with them. This obviously produces the threat of fingerprinting, and to mitigate fingerprinting we have the *miserable* constraint where you have to push a button to make your controller show up. This changes the ordinal identifiers of gamepads from session to session, and - even worse - means that a controller cannot be activated by analog stick inputs, which is a real problem for games that start with a menu (like two of my major ports). This defies user expectations and is just plain confusing. Polling an actual device to get its state is perfectly reasonable, but polling the overall state of your input devices is not so. Device availability is something that should be event-based (it is at a driver level anyway) and it should be exposed to content as events. The fingerprinting problem is addressed with the solution I proposed here: Content should *request* the input it needs, at which point the useragent is able to figure out how to provide it. To mitigate fingerprinting concerns, this can be done based on user consent, and the input presented to the content can end up fully sanitized, because the user content has no need to
Re: [DOM-Level-3-Events] Synthetic mouse events triggering default action
On Wed, Oct 15, 2014 at 2:40 AM, Bogdan Brinza bbri...@microsoft.com wrote: http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events That text is utterly broken as we've discussed several times now. Events do not cause action. Actions cause events (that can then prevent further action). There is one issue here with some implementations around a limited set of events, discussed to great length in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 -- https://annevankesteren.nl/
PSA: publish WD of Screen Orientation on Oct 21
Hi All, Mounir would like to publish a new WD of Screen Orientation and the target date for that publication is October 21: https://w3c.github.io/screen-orientation/ If anyone has any major concerns about this plan, please speak up as soon as possible. -Thanks, AB
[Bug 22228] Clarification of timeout attribute late overrides
https://www.w3.org/Bugs/Public/show_bug.cgi?id=8 Anne ann...@annevk.nl changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Anne ann...@annevk.nl --- https://github.com/whatwg/xhr/commit/2677cc2e0fe79d290437c3ea9ff370a5d795294b Sorry for taking so long in fixing this regression. -- You are receiving this mail because: You are on the CC list for the bug.
RE: [DOM-Level-3-Events] Synthetic mouse events triggering default action
-Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Wed, Oct 15, 2014 at 2:40 AM, Bogdan Brinza bbri...@microsoft.com wrote: http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events That text is utterly broken as we've discussed several times now. Yeah, I've got a bug to fix that. Will probably refactor to match basically what Sicking wrote in 12230. Events do not cause action. Actions cause events (that can then prevent further action). There is one issue here with some implementations around a limited set of events, discussed to great length in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 It looks like that bug is trending in the right direction. We have additional data to drop into that bug now to help Rick and others identify additional behaviors and sites that depend on them.
RE: [streams-api] Seeking status of the Streams API spec
I replaced the W3C Streams API spec WD with a pointer to the WHATWG Streams spec and a few sections discussing what we should add to the spec for browser use cases. This change means that the W3C Editor’s draft no longer defines the Stream interface as was previously supported. Would it be feasible to resurrect this interface as a layer on top of [1] so that W3C specifications like MSE that have a dependency on the Streams interface are not broken? /paulc [1] https://github.com/whatwg/streams Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Tuesday, October 14, 2014 11:06 PM To: Paul Cotton Cc: Jerry Smith (WINDOWS); Anne van Kesteren; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.org; Domenic Denicola; Aaron Colwell Subject: Re: [streams-api] Seeking status of the Streams API spec Re: establishing integration plan for the consumers and producers listed in the W3C spec, we haven't done anything than what Domenic introduced in this thread. I wrote some draft of XHR+ReadableStream integration spec and is implemented on Chrome, but the plan is not to ship it but wait for the Fetch API as discussed at WHATWG. On Wed, Oct 15, 2014 at 9:10 AM, Paul Cotton paul.cot...@microsoft.commailto:paul.cot...@microsoft.com wrote: This thread was recently re-started at http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0084.html Domenic's latest document is at https://streams.spec.whatwg.org/ The W3C document has NOT been updated since http://www.w3.org/TR/2013/WD-streams-api-20131105/ . Not to confuse people, too late but I replaced the W3C Streams API spec WD with a pointer to the WHATWG Streams spec and a few sections discussing what we should add to the spec for browser use cases. /paulc Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596tel:%28425%29%20705-9596 Fax: (425) 936-7329tel:%28425%29%20936-7329 -Original Message- From: Jerry Smith (WINDOWS) Sent: Tuesday, October 14, 2014 8:03 PM To: Domenic Denicola; Aaron Colwell Cc: Anne van Kesteren; Paul Cotton; Takeshi Yoshino; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.orgmailto:public-html-me...@w3.org Subject: RE: [streams-api] Seeking status of the Streams API spec Where is the latest Streams spec? https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm doesn't have much about WritableStreams. Jerry -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.commailto:dome...@domenicdenicola.com] Sent: Tuesday, October 14, 2014 10:18 AM To: Aaron Colwell Cc: Anne van Kesteren; Paul Cotton; Takeshi Yoshino; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.orgmailto:public-html-me...@w3.org Subject: RE: [streams-api] Seeking status of the Streams API spec From: Aaron Colwell [mailto:acolw...@google.commailto:acolw...@google.com] MSE is just too far along, has already gone through a fair amount of churn, and has major customers like YouTube and Netflix that I just don't want to break or force to migrate...again. Totally understandable. I haven't spent much time looking at the new Stream spec so I can't really say yet whether I agree with you or not. The main reason why people wanted to be able to append a stream is to handle larger, open range, appends without having to make multiple requests or wait for an XHR to complete before data could be appended. While I understand that you had your reasons to expand the scope of Streams to be more general, MSE really just needs them as a handle to route bytes being received with XHR to the SourceBuffer w/o having to actually surface them to JS. It would be really unfortunate if this was somehow lost in the conversion from the old spec. The way to do this in Streams is to pipe the fetch stream to a writable stream: fetch(url) .then(response = response.body.pipeTo(writableStream).closed) .then(() = console.log(all data written!)) .catch(e = console.log(error fetching or piping!, e)); By piping between two UA-controlled streams, you can establish an off-main-thread relationship between them. This is why it would be ideal for SourceBuffer (or a future alternative to it) to be WritableStream, especially given that it already has abort(), appendBuffer(), and various state-like properties that are very similar to what a WritableStream instance has. The benefit here being that people could then use SourceBuffers as generic destinations for any writable-stream-accepting code, since piping to a writable stream is idiomatic. But that said, given the churn issue I can understand it not being feasible or desirable to take that path. Perhaps, although I expect that there may be some resistance to dropping this at this point. Media folks were expecting the Streams API
RE: [streams-api] Seeking status of the Streams API spec
From: Paul Cotton [mailto:paul.cot...@microsoft.com] Would it be feasible to resurrect this interface as a layer on top of [1] so that W3C specifications like MSE that have a dependency on the Streams interface are not broken? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision.
RE: [streams-api] Seeking status of the Streams API spec
The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. This seems to contradict the direction that was published in Feb 2014 [1] in which it was clearly stated: In addition to the base Stream spec, the remaining platform-specific pieces which do not fit into the shared-base spec will live in an independent spec. This includes things such as support in other APIs (XHR, MediaStreaming, etc) or DOM specific scenarios - (createObjectURL()). The current W3C Streams API will focus on this aspect of the API surface, while leaving the core functionality to be defined in the base spec. It seems to me that layering a Stream interface in an independent spec would support other APIs like MSE. Why cannot this be done? /paulc [1] http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0218.html 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: Wednesday, October 15, 2014 2:25 PM To: Paul Cotton; Takeshi Yoshino Cc: Jerry Smith (WINDOWS); Anne van Kesteren; public-webapps; Arthur Barstow; Feras Moussa; public-html-me...@w3.org; Aaron Colwell Subject: RE: [streams-api] Seeking status of the Streams API spec From: Paul Cotton [mailto:paul.cot...@microsoft.com] Would it be feasible to resurrect this interface as a layer on top of [1] so that W3C specifications like MSE that have a dependency on the Streams interface are not broken? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision.
Re: [streams-api] Seeking status of the Streams API spec
On Wed, Oct 15, 2014 at 11:24 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Paul Cotton [mailto:paul.cot...@microsoft.com] Would it be feasible to resurrect this interface as a layer on top of [1] so that W3C specifications like MSE that have a dependency on the Streams interface are not broken? The decision we came to in web apps some months ago was that the interfaces in that spec would disappear in favor of WritableStream, ReadableStream, and the rest. The idea of a single Stream interface was not sound; that was one of the factors driving the conversations that led to that decision. This decision makes sense to me. I just need to sit down and read the new Streams spec to come up with a new proposal. The simplest solution looks like it would be to just change the Stream to ReadableStream in the existing appendStream() signature and then update the relevant algorithms to properly interact with that object. Like I said, I don't have enough knowledge yet to fully understand the implications of that yet. I plan to spend some quality time with the Stream spec sometime this week so I can get a better handle on this. I will probably have questions for Domenic and Takeshi, but I know where to find them. :) I believe the old Stream interface is only a problem for IE. I don't think any other browser has shipped it. While I am sensitive to the backwards compatibility issues, it isn't clear to me that we should stick to the old signature just because IE chose to ship a Stream object before the spec was in a more stable state. In some ways I feel like it is better that there are different object names because then this could just be handled like a method overload instead of trying to figure out how to distinguish 2 implementations with the same object name. Aaron
Push API and Service Workers
Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand whether the Service Workers is a must-have dependency for all scenarios. It seems some basic scenarios can be enabled without the Service Worker if the website can directly create a PushRegistrationManager. I'm looking at Fig. 1 in the spec. If the user agent can be the broker between the Push client and the webpage, it seems some generic actions can be defined without the Service Workers - for example immediately display a toast notification with the push message. It is very likely I have missed some basic design principle behind the current API design. It'd be great if someone could share insights on the scenarios and the normative dependency on the Service Workers. All the Best, Shijun
RE: Push API and Service Workers
I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling...), which would allow it to display a toast notification with the push message. So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities.
RE: Push API and Service Workers
My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, October 15, 2014 2:59 PM To: Shijun Sun; public-webapps Subject: RE: Push API and Service Workers I'm not an expert either, but it seems to me that push without service workers (or some other means of background processing) is basically just server-sent events. That is, you could send push notifications to an active webpage over a server-sent events channel (or web socket, or long-polling...), which would allow it to display a toast notification with the push message. So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities.
Re: Push API and Service Workers
The hard question is: What do you do if there's an incoming push message for a given website, but the user doesn't have the website currently open. Service Workers provide the primitive needed to enable launching a website in the background to handle the incoming push message. Another solution would be to always open up a browser tab with the website in it. But that's only correct behavior for some types of push messages. I.e. some push messages should be handled without any UI being opened. Others should be opened by launching a attention window which is rendered even though the phone is locked. Others simply want to create a toast notification. We could add lots of different types of push messages. But that's a lot of extra complexity. And we'd have to add similar types of geofencing registrations, and types of alarm clock registrations, etc. The current design separates the trigger from what to do when the trigger fires. Which both makes for a smaller API, and for a more flexible design. / Jonas On Wed, Oct 15, 2014 at 2:42 PM, Shijun Sun shij...@microsoft.com wrote: Hi, I'm with the IE Platform team at Microsoft. I joined the WebApps WG very recently. I am looking into the Push API spec, and got some questions. Hope to get help from experts in the WG. The current API definition is based on an extension of the Service Workers. I'd like to understand whether the Service Workers is a must-have dependency for all scenarios. It seems some basic scenarios can be enabled without the Service Worker if the website can directly create a PushRegistrationManager. I'm looking at Fig. 1 in the spec. If the user agent can be the broker between the Push client and the webpage, it seems some generic actions can be defined without the Service Workers - for example immediately display a toast notification with the push message. It is very likely I have missed some basic design principle behind the current API design. It'd be great if someone could share insights on the scenarios and the normative dependency on the Service Workers. All the Best, Shijun
Re: Push API and Service Workers
On 15 October 2014 23:07, Shijun Sun shij...@microsoft.com wrote: My understanding here is that we want to leverage the push client in the OS. That will provide new capabilities without dependency on a direct connection between the app and the app server. The Push API doesn't use a direct connection between the app and the app server: instead it assumes that there is a direct connection between the UA and a push server of the UA's choice. Then the app server can send messages to the push server, which relays them to the UA, which delivers them to the Service Worker. For example Android devices already maintain a persistent connection to Google Cloud Messaging (GCM) servers, so in our current prototype in Chrome for Android, we set GCM as the endpoint https://w3c.github.io/push-api/#widl-PushRegistration-endpoint to which the app server sends messages, and GCM relays the messages to the Android device, which wakes up Chrome, which launches a Service Worker, and then app JS handles the message. --John
Re: Push API and Service Workers
On 15 October 2014 14:58, Domenic Denicola dome...@domenicdenicola.com wrote: So from my perspective, implementing the push API without service workers would be pretty pointless, as it would give no new capabilities. That's not strictly true. If I sit (as I do) with a tab open to gmail for a very long time, then it is of some advantage to me (and my network usage) to use something like push rather than websockets (or even server sent events). Besides, server sent events might be roughly equivalent, but they are horribly kludgy and suffer from robustness issues.
RE: [DOM-Level-3-Events] Synthetic mouse events triggering default action
-Original Message- From: Travis Leithead Sent: Wednesday, October 15, 2014 10:53 AM To: Anne van Kesteren; Bogdan Brinza Cc: public-webapps@w3.org Subject: RE: [DOM-Level-3-Events] Synthetic mouse events triggering default action -Original Message- From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Wed, Oct 15, 2014 at 2:40 AM, Bogdan Brinza bbri...@microsoft.com wrote: http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events That text is utterly broken as we've discussed several times now. Yeah, I've got a bug to fix that. Will probably refactor to match basically what Sicking wrote in 12230. Events do not cause action. Actions cause events (that can then prevent further action). There is one issue here with some implementations around a limited set of events, discussed to great length in this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 It looks like that bug is trending in the right direction. We have additional data to drop into that bug now to help Rick and others identify additional behaviors and sites that depend on them. Thanks for clarifications. Based on discussion in the bug (thanks Travis for adding further details!) I've filed crbug.com/423975 for this specific issue.
RE: Push API and Service Workers
Thanks folks for the quick responses to the questions! RE: [Martin Thomson] If I sit (as I do) with a tab open to gmail for a very long time, then it is of some advantage to me (and my network usage) to use something like push rather than websockets (or even server sent events). Besides, server sent events might be roughly equivalent, but they are horribly kludgy and suffer from robustness issues. I think Martin made a very good point. For mobile devices, it is certainly undesirable to keep the websockets for a long time. RE: [Jonas Sicking] The current design separates the trigger from what to do when the trigger fires. Which both makes for a smaller API, and for a more flexible design. That is a valid argument. To be clear, my question right now is not whether we need Service Workers in the spec. I'd like to understand how that works in typical scenarios and whether we need it in all scenarios. RE: [John Mellor] For example Android devices already maintain a persistent connection to Google Cloud Messaging (GCM) servers, so in our current prototype in Chrome for Android, we set GCM as the endpoint to which the app server sends messages, and GCM relays the messages to the Android device, which wakes up Chrome, which launches a Service Worker, and then app JS handles the message. My expectation would be the device (i.e. the push client) will pass the message to the Service Worker (when it is active), and then the Service Worker will wake up the browser. Anyway, my excuse to be new to the area ;-) Let's take the GCM example from another angle. Assuming we have a WebRTC app, which has registered for a push notification at GCM. Now there is an incoming video call, while the browser is still inactive. The notification from the web server will go to the GCM, which relays it to the device push client, which displays a toast notification *right away*, when user clicks, the browser is launched with the webapp to take the call. Is this a reasonable expectation for the E2E scenario? Would there be extra latency if we want to wait for the Service Worker to be ready (based on its schedule), which then pushes a web notification for user to take the call (or dismiss the call)? Best, Shijun
