On Wed, Sep 21, 2011 at 8:52 PM, Israel Hilerio wrote:
> Sounds good! The updated example will look like this:
> var myDictionary = { bubbles: true, cancellable: true, oldVersion=1,
> newVersion=2};
> var changeEvent = new IDBVersionChangeEvent("versionchange", myDictionary);
>
The common pattern
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 IndexedDB spec to the new version API!
>> > Definite
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 for people to have a look at it
>>
On Wed, Sep 21, 2011 at 8:32 PM, Eric U wrote:
> 5.6.3 is a "substep", not a "step"; all of 5's substeps are referred
> to as such in step 5: "Otherwise run these substeps:". However, I
> believe we were actually discussing 5.5, loadend on the XHR itself.
> Either way, the below applies to both.
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 incorporating the new Event
>> constructor model def
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 incorporating the new Event
> constructor model defined in DOM 4.
> >
> > [Constructor(DOMString type, optional IDB
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: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 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 "again"; this is the first time I've described
this behavior.
Update: I have made the changes to FileWriter/FileSaver's event
sequences; they now match FileReader.
That's not to say it won't change pending discussion, but FileWriter
should continue to match FileReader whatever else happens.
Eric
On Wed, Sep 21, 2011 at 4:45 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 6:51 PM, Eric U wrote:
>>
>> While it's certainly not hard to work around, as you say, it seems
>> more complex and less likely to be obvious than the
>> counter-for-activity example, which feels like the classic push
On Wed, Sep 21, 2011 at 6:51 PM, Eric U wrote:
> While it's certainly not hard to work around, as you say, it seems
> more complex and less likely to be obvious than the
> counter-for-activity example, which feels like the classic push-pop
> paradigm.
The *need* to have counters to use loadstar
On Wed, Sep 21, 2011 at 3:29 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 6:14 PM, Eric U wrote:
>>
>> If we eliminate it entirely, then you can't ever start a new read on
>> the same object from the abort handler. That seems like a reasonable
>> use case.
>
> It's trivial to stuff it into
On Wed, Sep 21, 2011 at 6:14 PM, Eric U wrote:
> If we eliminate it entirely, then you can't ever start a new read on
> the same object from the abort handler. That seems like a reasonable
> use case.
>
It's trivial to stuff it into a zero-second timeout to knock it out of the
event handler. T
On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 5:44 PM, Eric U wrote:
>>
>> If we want the file specs to match the XHR spec, then we can just
>> leave this as it is in File Reader, and I'll match it in File Writer.
>> Recursion depth limit is up to the UA to set.
On Wed, Sep 21, 2011 at 5:44 PM, Eric U wrote:
> If we want the file specs to match the XHR spec, then we can just
> leave this as it is in File Reader, and I'll match it in File Writer.
> Recursion depth limit is up to the UA to set. But I look forward to
> hearing what Anne has to say about it
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 quick skim of XHR and XHR2, that's not what
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: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 quick skim of XHR and XHR2, that's not what
>>> they do. They let open() terminate abort(), however fa
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 quick skim of XHR and XHR2, that's not what
>> they do. They let open() terminate abort(), however far along it's
>> gotten. If we did that, then an abort killed
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
Awesome you are adopting this!
On Wed, 21 Sep 2011 20:58:22 +0200, Israel Hilerio
wrote:
This is our interpretation of how we see incorporating the new Event
constructor model defined in DOM 4.
[Constructor(DOMString type, optional IDBVersionChangeEventInit
IDBVersionChangeEventInitDict)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14231
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13811
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 IDBVersionChangeEvent : Event {
readonly attribute DOMString oldVersion;
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13957
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Sep 20, 2011 at 8:40 PM, Eric U wrote:
> Indeed--however, from a quick skim of XHR and XHR2, that's not what
> they do. They let open() terminate abort(), however far along it's
> gotten. If we did that, then an abort killed by a read might lead to
> the aborted read never getting an on
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13996
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14231
Summary: Force values of runs of consecutive nodes, not
individual nodes
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
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:
We add IDBFactory.getDatabaseNames() which asynchronously de
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14062
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14066
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 09/20/2011 11:27 PM, Bjoern Hoehrmann wrote:
with the Web Applications Working Group, which after six years has a
XMLHttpRequest test suite consisting of nothing but "There is a good
chance a test suite for XMLHttpRequest will be placed around here" and
no XMLHttpRequest specification to show.
A neat side effect of not rendering the host element (whether by "display:
transparent", or implicitly) is that encapsulated styling of a component
becomes trivial. I.e., one may want a component be isolated (i.e., not be
able to access the main document by default, and vice versa), but still
style
34 matches
Mail list logo
