Re: [IndexedDB] onsuccess isn’t the best for writes

On Mon, Mar 19, 2012 at 7:01 PM, Glenn Maynard wrote: > Unrelated: > > "If an exception was propagated out from any event handler while dispatching > the event in step 3, abort the transaction by following the steps for > aborting a transaction using transaction as transaction parameter, and > Abo

Re: [IndexedDB] onsuccess isn’t the best for writes

Unrelated: "If an exception was propagated out from any event handler while dispatching the event in step 3, abort the transaction by following the steps for aborting a transaction using transaction as transaction parameter, and AbortError as error." Exceptions don't propagate out of event handle

Re: [DOM4] Question about using sequence v.s., NodeList for

Hi Ojam, all, Thanks for the feedback. I have updated the proposed changes (http://wiki.csswg.org/spec/css3-regions/css-om) to use a static NodeList for Nodes and sequence for Ranges and Regions. Cheers, -v From: Ojan Vafai mailto:o...@chromium.org>> Date: Fri, 16 Mar 2012 18:45:08 -0700 To: A

Re: [IndexedDB] onsuccess isn’t the best for writes

On Mon, Mar 19, 2012 at 4:59 PM, Glenn Maynard wrote: > On Fri, Mar 16, 2012 at 6:24 AM, Yonathan wrote: >> >> Should the specification encourage onsuccess >> >> for reads and oncomplete for writes? > > > I don't think any amount of documentation is going to stop this from being > confusing.  Com

Re: [IndexedDB] onsuccess isn’t the best for writes

On Fri, Mar 16, 2012 at 6:24 AM, Yonathan wrote: > Should the specification encourage onsuccess for reads and oncomplete for writes? > I don't think any amount of documentation is going to stop this from being confusing. Committing transactions should really have been an explicit request with

Re: Colliding FileWriters

On Mon, Mar 19, 2012 at 3:10 PM, Eric U wrote: > On Wed, Feb 29, 2012 at 8:44 AM, Eric U wrote: >> On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: >>> On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: >> One working subset would be: >> >> * Keep createFileWriter async. >> *

Re: Colliding FileWriters

On Wed, Feb 29, 2012 at 8:44 AM, Eric U wrote: > On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: >> On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: > One working subset would be: > > * Keep createFileWriter async. > * Make it optionally exclusive [possibly by default].  If

Re: Colliding FileWriters

On Wed, Feb 29, 2012 at 8:44 AM, Eric U wrote: > On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: >> On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: > One working subset would be: > > * Keep createFileWriter async. > * Make it optionally exclusive [possibly by default].  If

Re: (aside) MIME type

On 2012-02-21 21:32, Bjoern Hoehrmann wrote: * Mark Baker wrote: I wish they did, consistently. See RFC 4288 (just "media type") and the registry itself ("MIME media type") . Plus they're still routinely referred to as "MIME types" in many

Re: [IndexedDB] onsuccess isn’t the best for writes

On Mon, Mar 19, 2012 at 12:31 PM, Jonas Sicking wrote: > That sounds good to me. Can you file a bug in our bugzilla? Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16441

[Bug 16441] New: Spec should note that onsuccess shouldn’t be used for writes.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16441 Summary: Spec should note that onsuccess shouldn’t be used for writes. Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW

[webcomponents] Progress Update

Hello, public-webapps! Here's another summary of work, happening in Web Components. SHADOW DOM (https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978) * First bits of the Shadow DOM test suite have landed: http://w3c-test.org/webapps/ShadowDOM/tests/submissions/Google/tests.html * More w

Re: [IndexedDB] onsuccess isn’t the best for writes

That sounds good to me. Can you file a bug in our bugzilla? Though note that the situation is a bit more complex. If a page expects that a write can fail with a ConstraintError then the page might want to listen to the error event and call preventDefault() on it. But yeah, I agree that listening

Call for Review: Web Audio API

Hi, folks- The Audio Working Group published an updated Working Draft of Web Audio API [1] on 15 March 2012. From the introduction: [[ This specification describes a high-level JavaScript API for processing and synthesizing audio in web applications. The primary paradigm is of an audio routi

Re: Regarding app notification and wake up

I second Bryan's request. Having apps that need to monitor remote events each spawn a (shared)worker to do so could drain a phone's battery very quickly. There needs to be a system-level way to do this. --tobie On 3/12/12 11:47 PM, "SULLIVAN, BRYAN L" wrote: >Karl, excellent questions. > >Re

RE: CfC: publish Candidate Recommendation of Web IDL; deadline March 26

>-Original Message- >From: Charles McCathieNevile [mailto:cha...@opera.com] > >On Mon, 19 Mar 2012 12:24:23 +0100, Marcos Caceres wrote: >> On Monday, 19 March 2012 at 10:58, Arthur Barstow wrote: >> >>> Cameron has addressed the comments from Web IDL LC#3 [1] and the bug >>> list only con

Re: CfC: publish Candidate Recommendation of Web IDL; deadline March 26

On Mon, 19 Mar 2012 12:24:23 +0100, Marcos Caceres wrote: On Monday, 19 March 2012 at 10:58, Arthur Barstow wrote: Cameron has addressed the comments from Web IDL LC#3 [1] and the bug list only contains two enhancement requests [2]. As such, this is a call for consensus to publish a Candidate

Re: CfC: publish Candidate Recommendation of Web IDL; deadline March 26

On Monday, 19 March 2012 at 10:58, Arthur Barstow wrote: > Cameron has addressed the comments from Web IDL LC#3 [1] and the bug > list only contains two enhancement requests [2]. As such, this is a call > for consensus to publish a Candidate Recommendation of Web IDL using the > following

[IndexedDB] onsuccess isn’t the best for writes

I’m concerned that people will listen to IDBRequest’s “success” event to notify when an add or put has been successfully written. For example, the “Using IndexedDB” article[1] recommends, “The first thing you'll want to do with almost all of the requests you generate is to add success and error han

Re: WebSockets -- only TCP?

no On Mon, Mar 19, 2012 at 1:09 AM, Rick van Rein wrote: > Hello, > > > See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html > > Ah, I was looking in the wrong place then :) > > Is this considered as part of the HTML5 specification? >

Re: WebSockets -- only TCP?

Hello, > See PeerConnection in http://dev.w3.org/2011/webrtc/editor/webrtc.html Ah, I was looking in the wrong place then :) Is this considered as part of the HTML5 specification? Thanks, -Rick