.push and .pop are generic and work on anything that looks like an
Array. However they don't work on NodeList because NodeList isn't
mutable.
> On Thu, Aug 25, 2011 at 3:03 AM, Jonas Sicking wrote:
>> On Wed, Aug 24, 2011 at 11:47 PM, Julien Richard-Foy
>> wrote:
>>
On Mon, Aug 22, 2011 at 2:47 AM, James Graham wrote:
> On 08/22/2011 11:22 AM, Jonas Sicking wrote:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/complete/
>>
>> I *always* used the much smaller document that used to be available here:
>>
>> www.wh
Awesome list!
> 1. Sections: 3.1.2 Object Store
> Issue Text: specify that generators are not shared between stores.
> Feedback: We prefer this approach. We should state this in the spec and
> remove the issue.
Agreed. This was the intent, but it might not be spelled out.
Generators are not sha
On Mon, Aug 29, 2011 at 9:40 AM, Aryeh Gregor wrote:
> On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking wrote:
>> .push and .pop are generic and work on anything that looks like an
>> Array. However they don't work on NodeList because NodeList isn't
>> mutable.
>
On Tue, Aug 30, 2011 at 2:32 AM, Julien Richard-Foy
wrote:
> On Aug 30, 2011, at 10:33 AM, Jonas Sicking wrote:
>> My point was that it was a mistake for querySelectorAll to return a
>> NodeList. It should have returned an Array. Sounds like people agree
>> with that then?
&g
On Tue, Aug 30, 2011 at 2:25 PM, Aryeh Gregor wrote:
> On Tue, Aug 30, 2011 at 4:33 AM, Jonas Sicking wrote:
>> My point was that it was a mistake for querySelectorAll to return a
>> NodeList. It should have returned an Array. Sounds like people agree
>> with that the
On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard wrote:
> On 8/24/2011 11:56 PM, Charles Pritchard wrote:
>>
>> On 8/24/11 11:36 PM, Jonas Sicking wrote:
>>>
>>> On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard
>>> wrote:
>>>>>>
&g
On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa wrote:
> On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler wrote:
>>
>> My question was not about the undo command. I meant that if I implemented
>> a handler for the aftereditaction event that changed b tags to strong tags,
>> how would the undo machinery
On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard wrote:
> On 8/30/11 5:52 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard
>> wrote:
>>
>>>
>>> On 8/24/2011 11:56 PM, Charles Pritchard wrote:
>>&
On Wed, Aug 31, 2011 at 12:07 AM, Charles Pritchard wrote:
> On 8/30/2011 7:11 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard
>> wrote:
>>>
>>> On 8/30/11 5:52 PM, Jonas Sicking wrote:
>>>>
>>>>
On Wed, Aug 31, 2011 at 8:25 AM, Anne van Kesteren wrote:
> I think defining all of these in one specification is fine. Currently the
> specification is only 37 pages when printed. That will certainly grow once
> we add ranges, examples, and more introductory text, but will also still be
> well be
On Wed, Aug 31, 2011 at 10:02 AM, Anne van Kesteren wrote:
> On Wed, 31 Aug 2011 18:52:34 +0200, Jonas Sicking wrote:
>>
>> Is this explicitly mentioned in the spec? Otherwise how will anyone be
>> able to take advantage of this fact?
>
> I guess we could explicitly m
On Wed, Aug 31, 2011 at 10:19 AM, Glenn Maynard wrote:
> On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking wrote:
>>
>> > Simple case:
>> > var callback = function(blob) { xhr.send(blob); };
>> > formData.toBlob(callback, 'multipart/form-data');
>
Hi All,
We've been working on finishing up our implementation of the WebSocket
API for firefox and have mostly one outstanding issue.
The problem is the .binaryType property. There are two problems that I
see with how it's currently defined.
1. It doesn't allow receiving textual messages as Blob
Hi Everyone,
I finally got around to updating the IndexedDB spec to the new version
API! Definitely a non-trivial change, so I'd love for people to have a
look at it to see if I messed anything up.
I decided to go with the name "upgradeneeded" for the event fired when
a version upgrade is needed.
Hi All,
The new DOM-Core specification changes some of the behavior for
DocType nodes to make them act more like all other nodes in the DOM.
Specifically:
1. They always have a ownerDocument
2. They can move between, both using explicit calls to AdoptNode, and
implicit adoption during for example
On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson wrote:
> On Thu, 8 Sep 2011, Jonas Sicking wrote:
>>
>> The new DOM-Core specification changes some of the behavior for DocType
>> nodes to make them act more like all other nodes in the DOM.
>> Specifically:
>>
>&
>> Anything using the following functions which seem useless or otherwise
>> have been discussed to be removed:
>> Node.isSameNode
>> Text.replaceWholeText
>
> Could not find the former, noted the latter. I did not know by the way we
> wanted to remove isSameNode(). Works for me.
a.isSameNode(b)
It's a completely useless function. It just implements the equality
operator. I believe most languages have a equality operator already.
Except Brainfuck [1]. But the DOM isn't implementable in Brainfuck
anyway as it doesn't have objects, so I'm ok with that.
[1] http://en.wikipedia.org/wiki/Brain
On Fri, Sep 9, 2011 at 2:27 PM, Sean Hogan wrote:
> On 10/09/11 3:21 AM, Jonas Sicking wrote:
>>
>> It's a completely useless function. It just implements the equality
>> operator. I believe most languages have a equality operator already.
>> Except Brainfuck [1].
On Fri, Sep 9, 2011 at 3:42 PM, Charles Pritchard wrote:
> On Sep 9, 2011, at 2:27 PM, Sean Hogan wrote:
>
>> On 10/09/11 3:21 AM, Jonas Sicking wrote:
>>> It's a completely useless function. It just implements the equality
>>> operator. I believe most languag
Trying to cut to the important bits, so skipped a lot.
On Sat, Sep 3, 2011 at 12:31 PM, Ian Hickson wrote:
>> Regarding 1:
>> The usecase for blobs in general would be downloading large messages
>> where the contents of the message won't be immediately used, but
>> rather stored for later use. Fo
On Fri, Sep 9, 2011 at 7:24 PM, Bjoern Hoehrmann wrote:
> * Jonas Sicking wrote:
>>It's a completely useless function. It just implements the equality
>>operator. I believe most languages have a equality operator already.
>
> It's quite normal for object mo
On Fri, Sep 9, 2011 at 8:05 PM, Charles Pritchard wrote:
> On 9/9/2011 6:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Sep 9, 2011 at 3:42 PM, Charles Pritchard wrote:
>>>
>>> On Sep 9, 2011, at 2:27 PM, Sean Hogan wrote:
>>>
>>>> On 10/
On Friday, September 16, 2011, Joshua Bell wrote:
> There appears to be a minor edge case in the IndexedDB draft (
http://www.w3.org/TR/IndexedDB) - and inconsistencies between
implementations - for the ECMAScript "negative zero" number value. While the
other numeric edge cases - NaN and +/-Infini
On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan wrote:
>> On 5/23/11 6:14 PM, Arun Ranganathan wrote:
>>
>> On 5/23/11 1:20 PM, Kyle Huey wrote:
>>
>> To close the loop a bit here, Firefox 6 will make the change to
>> FileReader.abort()'s throwin
On Tue, Sep 20, 2011 at 4:28 PM, Eric U wrote:
> On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
>> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan wrote:
>>> On 5/23/11 6:14 PM, Arun Ranganathan wrote:
>>>
>>> On 5/23/11 1:20 PM, Kyle Huey wrote:
>>>
>>> To close the loop a bit here, Firefox 6
On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard wrote:
> On Tue, Sep 20, 2011 at 8:01 PM, Eric U wrote:
>>
>> I have a read running, and at some point I abort it--it could be in
>> onprogress or elsewhere. In onabort I start another read. In
>> onloadstart I abort again. Repeat as many times as
On Wed, Sep 21, 2011 at 10:18 AM, Joshua Bell wrote:
> We've received feedback from early users of Chrome's implementation of
> IndexedDB requesting the ability to enumerate databases exist within an
> origin. We'd like the propose the following API addition to the IndexedDB
> API.
> TL;DR version
ng abort,
>> we'd probably want to do that by setting an "aborting" flag or mucking
>> around with yet another readyState of ABORTING.
>
> That's annoying, but it's better than the current situation, and I think
> better than the XHR situation. Receiving loa
On Wed, Sep 21, 2011 at 11:58 AM, Israel Hilerio wrote:
> Jonas,
>
> This is our interpretation of how we see incorporating the new Event
> constructor model defined in DOM 4.
>
> [Constructor(DOMString type, optional IDBVersionChangeEventInit
> IDBVersionChangeEventInitDict)]
> interface IDBVer
On Wed, Sep 21, 2011 at 2:44 PM, Eric U wrote:
> On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking wrote:
>> On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard wrote:
>>> On Tue, Sep 20, 2011 at 8:40 PM, Eric U wrote:
>>>>
>>>> Indeed--however, from a q
On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 7:51 PM, Eric U wrote:
>>
>> Again, that's not what the XHR2 spec says. See my summary up-thread
>> about the actual behavior, and Anne can correct my interpretation if
>> I'm wrong.
>
> I don't know what you mean by
On Wed, Sep 21, 2011 at 5:52 PM, Israel Hilerio wrote:
> On Wednesday, September 21, 2011 2:50 PM, Jonas Sicking wrote:
>> On Wed, Sep 21, 2011 at 11:58 AM, Israel Hilerio
>> wrote:
>> > Jonas,
>> >
>> > This is our interpretation of how we see incorp
On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio wrote:
> On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
>> Hi Everyone,
>>
>> I finally got around to updating the IndexedDB spec to the new version API!
>> Definitely a non-trivial change, so I'd love
On Mon, Sep 12, 2011 at 2:37 PM, Israel Hilerio wrote:
> On Monday, September 12, 2011 1:56 PM, Israel Hilerio wrote:
>> On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
>> > Hi Everyone,
>> >
>> > I finally got around to updating the I
On Thu, Sep 22, 2011 at 6:33 AM, Henri Sivonen wrote:
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#document-response-entity-body
> says:
> "If final MIME type is text/html let document be Document object that
> represents the response entity body parsed following the rules set
> forth in the
On Fri, Sep 23, 2011 at 1:26 AM, Henri Sivonen wrote:
> On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking wrote:
>> I agree that there are no legacy requirements on XHR here, however I
>> don't think that that is the only thing that we should look at. We
>> should a
On Fri, Sep 23, 2011 at 4:46 AM, Henri Sivonen wrote:
> On Fri, Sep 23, 2011 at 11:26 AM, Henri Sivonen wrote:
>> Applying all the legacy text/html craziness
>
> Furthermore, applying full legacy text/html craziness involves parser
> restarts for GET requests. With a browsing context, that means
Please don't use errorCallback/SuccessCallback. That's not used in any
other APIs that are part of the cross-browser web platform. Instead
return a request object on which events are fired.
Don't use enums as the syntax sucks in JS. Use strings instead. We're
making the same transition in a lot of
On Mon, Sep 26, 2011 at 5:18 PM, Charles Pritchard wrote:
> What's the alternative to the callback style from the proposal? It should be
> async, as both requesting and checking quota may require async requests.
See IDBRequest.
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-
On Tue, Sep 27, 2011 at 6:12 AM, Kinuko Yasuda wrote:
> Just to confirm: Yes the interfaces are vendor prefixed (WebKit), and
> WebSQL, AppCache, IDB are treated as temporary in the current chromium
> implementation.
> On Tue, Sep 27, 2011 at 8:53 AM, Charles Pritchard wrote:
>>
>> Any ideas on
On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio wrote:
> On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
>> On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio
>> wrote:
>> > On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
>> >> Hi
On Mon, Sep 26, 2011 at 7:50 AM, Henri Sivonen wrote:
> On Mon, Sep 26, 2011 at 12:46 PM, Jonas Sicking wrote:
>> On Fri, Sep 23, 2011 at 1:26 AM, Henri Sivonen wrote:
>>> On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking wrote:
>>>> I agree that there are no l
On Tue, Sep 27, 2011 at 11:10 PM, Anne van Kesteren wrote:
> On Wed, 28 Sep 2011 03:16:46 +0200, Jonas Sicking wrote:
>>
>> So it sounds like your argument is that we should do prescan
>> because we can do it without breaking any new ground. Not because it's
>>
On Wed, Sep 28, 2011 at 2:54 AM, Henri Sivonen wrote:
> On Wed, Sep 28, 2011 at 4:16 AM, Jonas Sicking wrote:
>> So it sounds like your argument is that we should do prescan
>> because we can do it without breaking any new ground. Not because it's
>> better or was inhe
On Wed, Sep 28, 2011 at 3:55 PM, Israel Hilerio wrote:
> On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
>> On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio
>> wrote:
>> > On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
>> >> On
On Mon, Sep 26, 2011 at 5:40 PM, Israel Hilerio wrote:
> On Monday, September 26, 2011 2:36 AM Anne van Kesteren wrote:
>> On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren
>>
>> wrote:
>> > On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio
>> > wrote:
>> >> This is our understanding on how
On Thu, Sep 29, 2011 at 12:03 AM, Henri Sivonen wrote:
> On Thu, Sep 29, 2011 at 3:30 AM, Jonas Sicking wrote:
>> Do we have any guesses or data as to what percentage of existing pages
>> would parse correctly with the above suggestion?
>
> I don't have guesses or
On Fri, Sep 30, 2011 at 5:40 AM, Henri Sivonen wrote:
> On Fri, Sep 30, 2011 at 3:35 PM, Anne van Kesteren wrote:
>> On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen wrote:
>>>
>>> On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren
>>> wrote:
I do not see why "text" and "moz-chunked-
On Fri, Sep 30, 2011 at 5:47 AM, Anne van Kesteren wrote:
> On Fri, 30 Sep 2011 14:40:09 +0200, Henri Sivonen wrote:
>>
>> responseType is a newish feature. If it's OK for responseType ==
>> "chunked-text" to use encoding determination rules that differ from
>> responseType == "" or responseType
On Fri, Sep 30, 2011 at 12:11 PM, Anne van Kesteren wrote:
> On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking wrote:
>>
>> Hmm.. I looked through archives but can't find any such decision.
>>
>> It's not how Gecko works, but I haven't tried webkit.
>
On Fri, Sep 30, 2011 at 4:57 PM, Joshua Bell wrote:
> In the WebIDL snippet and description for IDBFactory, the cmp method is
> defined as returning "int" which isn't defined in WebIDL (that I can see);
> presumably this should be "long" or one of the other signed numeric types?
> (short, byte, lo
On Sat, Oct 1, 2011 at 12:03 AM, Anne van Kesteren wrote:
> On Fri, 30 Sep 2011 21:41:39 +0200, Jonas Sicking wrote:
>>
>> On Fri, Sep 30, 2011 at 12:11 PM, Anne van Kesteren
>> wrote:
>>>
>>> On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking
>
On Sun, Oct 2, 2011 at 12:08 AM, Anne van Kesteren wrote:
> On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking wrote:
>>>
>>> If we change how determining encoding works between default, "text", and
>>> "document", we should really start
On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell wrote:
> As we're implementing IDBFactory.cmp in WebKit we noticed that the
> ordering sense is reversed compared to C's strcmp/memcmp, Perl's cmp/<=>
> operators, etc.
> As currently spec'd, IDBFactory.cmp(first, second) returns 1 if first
> < second
>
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan wrote:
> On 9/30/11 9:46 PM, Adrian Bateman wrote:
>>
>> Hi Arun,
>>
>> Thanks for the follow-up - you beat me to it. We've been reviewing this in
>> the context of the other specs and, as Israel outlined for IndexedDB,
>> we're
>> happy with the n
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren wrote:
> On Thu, 29 Sep 2011 23:17:21 +0200, Eric U wrote:
>>
>> I think that works; #2 will be especially important.
>> However, if I read this right, we *don't* have the invariant that a
>> loadstart will always have a loadend.
>> Now that Anne
On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking wrote:
>>
>> Unfortunately I suspect wanting to call open from event handlers is a
>> pretty common use case. Here are two use cases:
>>
>> 1. In case of a netwo
On Mon, Oct 3, 2011 at 4:26 PM, Ian Hickson wrote:
> On Mon, 3 Oct 2011, Arun Ranganathan wrote:
>>
>> Cc'ing Hixie as well to comment on what HTML might need.
>
> As far as I'm concerned, what HTML has now is fine (DOMException based
> on how DOM Core defines it).
>
>
>> > I'll leave this one for
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan wrote:
> On 10/3/11 4:59 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan
>> wrote:
>>>
>>> On 9/30/11 9:46 PM, Adrian Bateman wrote:
>>>>
>>>> Hi Arun
On Mon, Oct 3, 2011 at 5:10 PM, Joshua Bell wrote:
> On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio
> wrote:
>>
>> On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
>> > NON_TRANSIENT_ERR
>> > I think in many cases we should simply throw a Typ
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking wrote:
>>
>> 1. Make "loadend" not fire in case a new load is started from
>> onabort/onload/onerror. Thus "loadend" and "loadstart" isn'
On Mon, Oct 3, 2011 at 6:00 PM, Ian Hickson wrote:
> On Mon, 3 Oct 2011, Jonas Sicking wrote:
>>
>> I looked at how for example WebSockets and EventSource exposes error
>> information. I would have thought in both cases that it would have been
>> done as a property o
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio wrote:
> On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
>> For several of these I think we can reuse existing DOMExceptions.
>> Here's how I'd map the exceptions which are currently in the IndexedDB
>>
On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio wrote:
> Jonas,
>
> We’re removing error code values as part of the new exception type model.
> This will impact the IDBRequest.errorCode property. I believe we want to
> rename this property to errorName and change its type to DOMString in order
> t
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking wrote:
>>
>> So what exactly are you proposing we do for XHR and for
>> FileReader/FileWriter?
>
> For APIs other than XHR, don't allow calling read* or abort dur
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio wrote:
> Based on previous conversations, it seems we've agreed that there are
> situations in which a transaction could failed independent of explicit
> requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be
> represented as an impl
On Mon, Oct 3, 2011 at 7:17 PM, Jonas Sicking wrote:
> IDBDatabase(Sync).createObjectStore if the options argument is handed
> an object with properties other than those in the dictionary.
> This doesn't actually match how dictionaries are supposed to behave
> per WebIDL. Th
On Mon, Oct 3, 2011 at 11:54 PM, Anne van Kesteren wrote:
> On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking wrote:
>>
>> Yup. I do wonder if we should introduce a DOMError class which can be
>> reused in various cases which need APIs like this. IndexedDB could
>>
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking wrote:
> On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio wrote:
>> Based on previous conversations, it seems we've agreed that there are
>> situations in which a transaction could failed independent of explicit
>>
On Wed, Oct 5, 2011 at 1:14 AM, Marcos Caceres wrote:
> Would it be possible to add something to DOM4 to allow one to find out what
> language (xml:lang) was inherited from up the chain, if any?
>
> Use cases:
>
> 1. I need to find elements of a particular type/name that are in a particular
> la
Hi All,
In both the Firefox and the Chrome implementation you can pass an
empty array to IDBDatabase.transaction in order to create a
transaction which has a scope that covers all objectStores in the
database. I.e. you can do something like:
trans = db.transaction([]);
trans.objectStore();
(Note
On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio wrote:
> On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
>> Hi All,
>>
>> In both the Firefox and the Chrome implementation you can pass an empty
>> array to IDBDatabase.transaction in order to create a trans
Hi All,
There is one edge case regarding transaction scheduling that we'd like
to get clarified.
As the spec is written, it's clear what the following code should do:
trans1 = db.transaction(["foo"], IDBTransaction.READ_WRITE);
trans1.objectStore("foo").put("value 1", "mykey");
trans2 = db.trans
On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio wrote:
> On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
>> Hi All,
>>
>> In both the Firefox and the Chrome implementation you can pass an empty
>> array to IDBDatabase.transaction in order to create a trans
On Mon, Oct 10, 2011 at 7:44 AM, ben turner wrote:
> So it sounds like everyone agrees that accepting an empty array is not
> desired... Can we just make that case throw an exception rather than
> generating an empty transaction (which will then throw when it is
> used)?
I'm fine either way.
/ J
On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchard wrote:
> Is there interest or presence on this list from major SQL vendor developers
> such as PostgreSQL and MySQL?
>
> WebSQL received a thumbs-down from the postgresql developers mailing list.
> Now that that issue is over...
>
> MySQL and Post
On Mon, Oct 10, 2011 at 4:47 PM, Charles Pritchard wrote:
> On 10/10/2011 1:44 PM, Jonas Sicking wrote:
>>
>> On Mon, Oct 10, 2011 at 1:40 PM, Charles Pritchard
>> wrote:
>>>
>>> Is there interest or presence on this list from major SQL vendor
>>
On Mon, Oct 10, 2011 at 9:20 PM, Anne van Kesteren wrote:
> On Tue, 11 Oct 2011 12:53:35 +0900, Anne van Kesteren
> wrote:
>>
>> Currently if a resource sharing check fails cookies will still be set for
>> a credentialed request similarly to how they would be with or .
>> However, it seems that
On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio wrote:
> On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
>> On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking wrote:
>> > On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio
>> >
>> wrote:
>> >> Ba
Currently IDBObjectStore.count/get/openCursor and
IDBIndex.count/get/openCursor/openKeyCursor all take a key or a
KeyRange. However IDBObjectStore.delete only accepts keys. We should
fix this to allow .delete to accept a KeyRange as well.
/ Jonas
On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio wrote:
> If a db connection is closed inside the onupgradeneeded handler, section 4.1
> step #8 states that we should return an ABORT_ERR and abort steps. This
> implies that the transaction should fail. Since today, the db is closed after
> all r
On Wednesday, October 12, 2011, Israel Hilerio
wrote:
> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
>> On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio
>> wrote:
>> > If a db connection is closed inside the onupgradeneeded handler,
section 4.1
>>
On Thu, Oct 13, 2011 at 11:27 AM, Israel Hilerio wrote:
> On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote:
>>On Wednesday, October 12, 2011, Israel Hilerio wrote:
>>> On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
>>>> On Wed, Oct 12, 2
On Thu, Oct 13, 2011 at 10:57 AM, Israel Hilerio wrote:
> On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote:
>> On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio wrote:
>> > On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
>> >> On Mon, Oct 3, 2011 at
On Fri, Oct 14, 2011 at 2:27 PM, Israel Hilerio wrote:
> On Monday, October 10, 2011 10:15 AM, Israel Hilerio wrote:
>> On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote:
>> > On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio
>> >
>> > wrote:
>>
On Fri, Oct 14, 2011 at 2:57 PM, Israel Hilerio wrote:
> On Friday, October 14, 2011 2:43 PM, Jonas Sicking wrote:
>> On Fri, Oct 14, 2011 at 2:27 PM, Israel Hilerio
>> wrote:
>> > On Monday, October 10, 2011 10:15 AM, Israel Hilerio wrote:
>> >> On Mon
On Fri, Oct 14, 2011 at 1:51 PM, Israel Hilerio wrote:
> On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
>> On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
>> > Hi All,
>> >
>> > There is one edge case regarding transaction scheduling
On Mon, Oct 17, 2011 at 3:15 PM, Joshua Bell wrote:
> On Fri, Oct 14, 2011 at 4:02 PM, Israel Hilerio
> wrote:
>>
>> On Friday, October 14, 2011 3:57 PM, Jonas Sicking wrote:
>> > On Fri, Oct 14, 2011 at 2:57 PM, Israel Hilerio
>> > wrote:
>> >
Hi All,
Currently the spec is somewhat inconsistent in how it deals with
having an index on a property, and then inserting an object in an
object store which is either missing that property, or has the
property but with a value which is not a valid key.
Consider a database which has been set up a
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote:
> Lachlan and I have been having an...um...*spirited* twitter discussion
> regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
> and ":scope". He asked me to continue here, so I'll try to keep it
> short:
>
> The rooted forms of
On Wed, Oct 19, 2011 at 7:22 PM, Ojan Vafai wrote:
> On Wed, Oct 19, 2011 at 7:07 PM, Jonas Sicking wrote:
>>
>> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell
>> wrote:
>> > Lachlan and I have been having an...um...*spirited* twitter discussion
>> > re
On Wed, Oct 19, 2011 at 10:08 PM, Tab Atkins Jr. wrote:
> On Wed, Oct 19, 2011 at 7:22 PM, Ojan Vafai wrote:
>> On Wed, Oct 19, 2011 at 7:07 PM, Jonas Sicking wrote:
>>> .findAll("body > :scope > div") // returns nothing
>>
>> Wouldn't this
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote:
> Lachlan and I have been having an...um...*spirited* twitter discussion
> regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
> and ":scope". He asked me to continue here, so I'll try to keep it
> short:
>
> The rooted forms of
On Wed, Oct 19, 2011 at 11:14 PM, Sean Hogan wrote:
>> I do however like the idea that if :scope appears in the selector,
>> then this removes the prepending of ":scope " to that selector group.
>> Is there a reason not to do that?
>
> 1. Already supported (in the draft spec) by querySelectorAll()
On Thu, Oct 20, 2011 at 1:14 AM, Sean Hogan wrote:
> On 20/10/11 1:07 PM, Jonas Sicking wrote:
>>
>> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell
>> wrote:
>>>
>>> Lachlan and I have been having an...um...*spirited* twitter discussion
>&g
On Thu, Oct 20, 2011 at 2:13 AM, Lachlan Hunt wrote:
> On 2011-10-20 07:52, Jonas Sicking wrote:
>>
>> I'm not sure I understand what you are proposing here. Are you saying that
>>
>>
>>
>> :scope {
>> background: green;
>> }
>>
On Thu, Oct 20, 2011 at 3:46 AM, Alex Russell wrote:
>> However, it does seem like selectors are here to stay. And as much as
>> they have shortcomings, people seem to really like them for querying.
>>
>> So with that out of the way, I agree that the CSS working group
>> shouldn't be what is holdi
On Thu, Oct 20, 2011 at 3:50 AM, Alex Russell wrote:
> On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sicking wrote:
>> On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell wrote:
>>> Lachlan and I have been having an...um...*spirited* twitter discussion
>>> regarding quer
101 - 200 of 2094 matches
Mail list logo
