Reminder: RfC: LCWD of Pointer Lock; deadline November 28
Original Message Subject:RfC: LCWD of Pointer Lock; deadline November 28 Resent-Date:Thu, 31 Oct 2013 19:36:52 + Resent-From:public-webapps@w3.org Date: Thu, 31 Oct 2013 15:32:49 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org This is a Request for Comments for the Last Call Working Draft of Pointer Lock: http://www.w3.org/TR/2013/WD-pointerlock-20131031/ If you have any comments, please send them to public-webapps @ w3.org by November 28 using a Subject: header of [pointerlock]. -Thanks, AB
Re: CfC: publish Candidate Recommendation of File API; deadline November 28
On Thu, 21 Nov 2013 19:44:29 +0100, Arthur Barstow art.bars...@nokia.com wrote: Hi All, Arun completed processing the comments [Comments] for the Last Call version of File API [LCWD]. Although the comments resulted in changes to the spec (see [Diff]), no new features were added and the changes are considered bug fixes. The most significant change is the Constructor APIs in Section 7 - see [Section-7]. Arun proposes the spec be advanced to Candidate Recommendation and this is a Call for Consensus (CfC) to publish a CR using the following version as the basis: http://dev.w3.org/2006/webapi/FileAPI/ Please do. ... I propose 3 months as the minimal amount of time before we are ready to advance the spec to Propose Recommendation and I propose we re-use the CR exit criteria we used for the IDB CR: [[ During the Candidate Recommendation period, which ends @T+3months, the WG will complete its test suite. Before this specification exits Candidate Recommendation, two or more independent implementations must pass each test, although no single implementation must pass each test. I suggest s/each/every/ here just to disambiguate a bit more. But I can live with these as criteria. cheers chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Sync IO APIs in Shared Workers
On Thu, Nov 21, 2013 at 8:33 PM, Jonas Sicking jo...@sicking.cc wrote: One of the arguments made against sync APIs in workers made in [1] is that even for workers, it is often important to keep code responsive in order to react to actions taken by the user. The only relevant thing I can dig out of [1] can be summarized much more simply: we need a way to interrupt synchronous calls. It'd be tricky to allow interruption while still leading to robust code, but I think it's worth exploring. In principle it violates the don't expose asynchronous behavior principle, but in reality, asynchronous programming with messages coming from other threads does the same thing. We'd need to make sure it's very clear which calls can be interrupted, to avoid EINTR-like problems. But, we should explore the use cases more thoroughly first, to see if this is really needed. An alternative is to just terminate() the whole worker and start a new one. That's not very elegant, but it's very simple and robust: you don't end up with synchronous APIs throwing exceptions unexpectedly and worker code having to clean up after it. If the work is expensive enough that you need to cancel it, the cost of spinning up a new worker is negligible. Are there use cases where this doesn't work? I.e. while locking up a worker thread for an extended period of time won't cause problems like stuttered scrolling or UI that doesn't visually react when you click them, you can still end up with apps that seem unresponsive since the main thread is waiting to get back an answer from a worker thread that is busy. (This isn't an argument against sync APIs. The same thing will happen with async APIs if the page fails to give appropriate feedback to the user.) I also don't buy the argument that we can make async programming so convenient that there's little cost to async APIs compared to sync APIs. I think it's wishful thinking. My experience is that async programming is inherently less convenient than sync programming. Another solution would be to use real sync IO APIs, but expose an object in the parent thread which allows the parent to abort the current operation. (I'd use a MessagePort, eg. setCancellationPort(port), since the parent thread shouldn't be special.) Something else that could improve responsiveness while still allowing people to write synchronous code is the ability to check if there are pending messages on a channel without having to return to the event loop. That way the code can keep running until there's a message to process, and only return to the event loop when there is. http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html The proposal is to allow polling a MessagePort, retrieving the next message without having to return to the event loop. I think that's useful to allow number crunching workers to periodically check for new information, without having to return all the way to the event loop. It never got traction, though. One possible action here would be to disallow sync APIs in shared workers for now. This way we can use dedicated workers as a test bed to see if sync APIs are a problem, and if they are, if that problem can be fixed. This will just make people proxy messages from the shared worker to a dedicated worker, so nothing would change. I don't think making shared workers more different from dedicated workers than they have to be makes much sense. -- Glenn Maynard
Re: [HTML Imports]: Sync, async, -ish?
I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.com wrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.com wrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? As far as I know, script already blocks rendering and I don't think even Dimitri can change that ;-) Blocking script until HTML Import succeeds is not needed as we discussed earlier: scripts that want to run after Import already have an effective and well known mechanism to delay execution, listening for load events. - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.comwrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). Except that sync XHR is considered one of the great miss designs of the web and is causing huge UI issues for users and great pain for developers. If we had the opportunity we would remove it in a heartbeat. / Jonas
Re: [HTML Imports]: Sync, async, -ish?
I'm not talking about the script blocking as usual - I'm referencing the presence of a script causing the import to block until completed, when the script follows it. On Fri, Nov 22, 2013 at 8:57 AM, John J Barton johnjbar...@johnjbarton.comwrote: On Fri, Nov 22, 2013 at 8:22 AM, Daniel Buchner dan...@mozilla.comwrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). The best part of an explicit 'sync' attribute, is that we can now remove the block if a script comes after an import condition, right Dimitri? As far as I know, script already blocks rendering and I don't think even Dimitri can change that ;-) Blocking script until HTML Import succeeds is not needed as we discussed earlier: scripts that want to run after Import already have an effective and well known mechanism to delay execution, listening for load events. - Daniel On Nov 22, 2013 8:05 AM, John J Barton johnjbar...@johnjbarton.com wrote: I agree that we should allow developers to set 'sync' attribute on link tags to block rendering until load. That will allow them to create sites that appear to load slowly rather than render their standard HTML/CSS. I think that the default should be the current solution and 'sync' should be opt-in. Developers may choose: 1. Do nothing. The site looks fine when it renders before the components arrive. 2. Add small static content fixes. The site looks fine after a few simple HTML / CSS adjustments. 3. Add 'sync', the site flashes too much, let it block. This progression is the best for users. jjb On Thu, Nov 21, 2013 at 5:04 PM, Steve Souders soud...@google.comwrote: DanielF: You would only list the custom tags that should be treated as blocking. If *every* tag in Brick and Polymer should be blocking, then we have a really big issue because right now they're NOT-blocking and there's nothing in Web Components per se to specify a blocking behavior. JJB: Website owners aren't going to be happy with either situation: - If custom tags are async (backfilled) by default and the custom tag is a critical part of the page, subjecting users to a page that suddenly changes layout isn't good. - If custom tags (really HTML imports) are sync (block rendering) by default, then users stare at a blank screen during slow downloads. I believe we need to pick the best default while also giving developers the ability to choose what's best for them. Right now I don't see a way for a developer to choose to have a custom element block rendering, as opposed to be backfilled later. Do we think this is important? (I think so.) If so, what's a good way to let web devs make custom elements block? -Steve On Thu, Nov 21, 2013 at 3:07 PM, John J Barton johnjbar...@johnjbarton.com wrote: Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to invent AJAX so developers could control the user experience in the face of significant network delay. As I said earlier, most apps will turn this problem over to the design team rather than cause users to leave while the browser spins waiting for the page to render. On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner dan...@mozilla.comwrote: Yes, that's the primary motivation. Getting FUC'd is going to be a non-starter for serious app developers. We were just thinking of ways to satisfy the use-case without undue burden.
Re: [HTML Imports]: Sync, async, -ish?
Of course I realize this Jonas, but I assure you, if you burden the most common use-cases with poor ergonomics, developers will find even more ghastly ways to degrade perf. Can someone post an overview of the proposed solutions, and how they apply to the use-cases stated a few posts back? On Fri, Nov 22, 2013 at 9:05 AM, Jonas Sicking jo...@sicking.cc wrote: On Nov 22, 2013 8:24 AM, Daniel Buchner dan...@mozilla.com wrote: Personally I don't have any issues with this solution, it provides for the use-cases we face. Also, it isn't without precedent - you can opt for a sync XMLHttpRequest (not much different). Except that sync XHR is considered one of the great miss designs of the web and is causing huge UI issues for users and great pain for developers. If we had the opportunity we would remove it in a heartbeat. / Jonas
Re: Sync IO APIs in Shared Workers
On Fri, Nov 22, 2013 at 7:54 AM, Glenn Maynard gl...@zewt.org wrote: But, we should explore the use cases more thoroughly first, to see if this is really needed. An alternative is to just terminate() the whole worker and start a new one. That's not very elegant, but it's very simple and robust: you don't end up with synchronous APIs throwing exceptions unexpectedly and worker code having to clean up after it. If the work is expensive enough that you need to cancel it, the cost of spinning up a new worker is negligible. What data are you basing this statement on? Something else that could improve responsiveness while still allowing people to write synchronous code is the ability to check if there are pending messages on a channel without having to return to the event loop. That way the code can keep running until there's a message to process, and only return to the event loop when there is. http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1075.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0967.html The proposal is to allow polling a MessagePort, retrieving the next message without having to return to the event loop. I don't like that solution since it's very similar to spinning event loops in deep call stacks. Having worked on code bases which does event loop spinning on deep call stacks it's a horror I wouldn't want to impose on anyone. One possible action here would be to disallow sync APIs in shared workers for now. This way we can use dedicated workers as a test bed to see if sync APIs are a problem, and if they are, if that problem can be fixed. This will just make people proxy messages from the shared worker to a dedicated worker, so nothing would change. I don't think making shared workers more different from dedicated workers than they have to be makes much sense. People can already do things the wrong way is a terrible argument for introducing more ways of doing it the wrong way. The same argument could be used to say that we should add sync IO APIs on the main thread. It's already the case that you can write pages whose UI doesn't respond until you get a result back from a worker or an async IO operation. / Jonas
[testing] Seeking Test Facilitator(s) for Indexed Database API
[ Bcc: public-webapps-testsuite ] Hi All, We need help with the Indexed Database API testing effort. The general expectations for a Test Facilitator (TF) are defined in the testing Roles wiki [Roles]. For this spec, one of the first steps is to review the various submissions and recommend the set of tests WebApps should use to test the [CR] (and identify high priority gaps if there are any). After we have agreement on this set, those tests will need to be reviewed and the review can be done by multiple people. Group submissions: * Opera: https://github.com/w3c/web-platform-tests/pull/63 * Microsoft: https://github.com/w3c/web-platform-tests/pull/64 * Ms2ger: https://github.com/w3c/web-platform-tests/pull/65 TestTTWF Paris submissions: * BaptisteFontaine: https://github.com/w3c/web-platform-tests/pull/66 * ChristopheCharles: https://github.com/w3c/web-platform-tests/pull/67 * dgrogan: https://github.com/w3c/web-platform-tests/pull/68 * rhuet: https://github.com/w3c/web-platform-tests/pull/69 Please contact me if you can commit to helping with this effort and you have `relevant` experience. -Thanks, ArtB [Roles] http://www.w3.org/wiki/Webapps/Submitting_tests#Testing_Roles [CR] http://www.w3.org/TR/2013/CR-IndexedDB-20130704/ Original Message Subject: ACTION-704: Find another test facilitator for idb spec (Web Applications Working Group) Date: Tue, 12 Nov 2013 03:13:17 + From: ext Web Applications Working Group Issue Tracker sysbot+trac...@w3.org Reply-To: Web Applications Working Group public-webapps@w3.org To: art.bars...@nokia.com ACTION-704: Find another test facilitator for idb spec (Web Applications Working Group) http://www.w3.org/2008/webapps/track/actions/704 On: Arthur Barstow Due: 2013-11-19 If you do not want to be notified on new action items for this group, please update your settings at: http://www.w3.org/2008/webapps/track/users/7672#settings
Re: Sync IO APIs in Shared Workers
On Fri, Nov 22, 2013 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Nov 22, 2013 at 7:54 AM, Glenn Maynard gl...@zewt.org wrote: But, we should explore the use cases more thoroughly first, to see if this is really needed. An alternative is to just terminate() the whole worker and start a new one. That's not very elegant, but it's very simple and robust: you don't end up with synchronous APIs throwing exceptions unexpectedly and worker code having to clean up after it. If the work is expensive enough that you need to cancel it, the cost of spinning up a new worker is negligible. What data are you basing this statement on? If starting a worker is so expensive that this this is a real problem, that seems like a bug. If somebody is arguing that we should add a new API because creating a new worker is slow, then that's an optimization argument, and the burden of proof is on the claim that we need an optimization, not that we never do. The proposal is to allow polling a MessagePort, retrieving the next message without having to return to the event loop. I don't like that solution since it's very similar to spinning event loops in deep call stacks. Having worked on code bases which does event loop spinning on deep call stacks it's a horror I wouldn't want to impose on anyone. I don't think they're comparable. Spinning the event loop may have unrelated, unexpected side-effects, since it'll run tasks from any event source. This wouldn't have any effects like that at all; it would just check for messages on a specific MessagePort, and pop off and return the first one. It wouldn't pull a message from any port other than the one you're working with. One possible action here would be to disallow sync APIs in shared workers for now. This way we can use dedicated workers as a test bed to see if sync APIs are a problem, and if they are, if that problem can be fixed. This will just make people proxy messages from the shared worker to a dedicated worker, so nothing would change. I don't think making shared workers more different from dedicated workers than they have to be makes much sense. People can already do things the wrong way is a terrible argument for introducing more ways of doing it the wrong way. The same argument could be used to say that we should add sync IO APIs on the main thread. It's already the case that you can write pages whose UI doesn't respond until you get a result back from a worker or an async IO operation. I'm not convinced that synchronous work in shared workers *is* always the wrong way. For example, sharing client-side autocomplete in a single shared worker may be fine, since the user isn't going to be typing into two tabs simultaneously. And no, that's not the argument at all. The argument is that this is trivial to sidestep. The lack of sync APIs on the UI thread is hard or impossible to sidestep. -- Glenn Maynard
RTC in Web workers
Should RTC data channels be available in Workers and/or SharedWorker? Mainly: self.RTCPeerConnection self.RTCSessionDescription WebSocket and XHR are available, seems like RTC ought to be but isn't. -Charles
Re: Sync IO APIs in Shared Workers
On Fri, 22 Nov 2013 03:33:51 +0100, Jonas Sicking jo...@sicking.cc wrote: The only browser shipping SharedWorkers is Chrome (not sure if Opera does too?), Yes, both Presto-based (since Opera 10.60) and Chromium-based. -- Simon Pieters Opera Software
