W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [indexeddb] Updates to the Event Constructor to match DOM 4

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 21 Sep 2011 18:13:52 -0700
Message-ID: <CA+c2ei9pShcdzWTMzJAfRfD_6Vp_VPnNLy5xtHdAdT429=G4hw@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "annevk@opera.com" <annevk@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Sep 21, 2011 at 5:52 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Wednesday, September 21, 2011 2:50 PM, Jonas Sicking wrote:
>> On Wed, Sep 21, 2011 at 11:58 AM, Israel Hilerio <israelh@microsoft.com>
>> 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 IDBVersionChangeEvent :
>> > Event {
>> >     readonly attribute DOMString oldVersion;
>> >     readonly attribute DOMString newVersion;
>> >     void initIDBVersionChangeEvent (DOMString typeArg, boolean
>> > canBubbleArg, boolean cancelableArg, DOMString oldVersion, DOMString
>> > newVersion); };
>> >
>> > dictionary IDBVersionChangeEventInit : EventInit {
>> >   DOMString oldVersion;
>> >   DOMString newVersion;
>> > }
>>
>> Looks great apart from needing to remove the init function as Anne points
>> out.
>>
>
> Makes sense, I originally had it for interoperability but I see Anne's point.
>
> [Constructor(DOMString type, optional IDBVersionChangeEventInit
> IDBVersionChangeEventInitDict)] interface IDBVersionChangeEvent :
> Event {
>    readonly attribute DOMString oldVersion;
>    readonly attribute DOMString newVersion;
> };
>
> dictionary IDBVersionChangeEventInit : EventInit {
>   DOMString oldVersion;
>   DOMString newVersion;
> }
>
>> > We'll need to add a step between 3 and 4 to section 4.12 and a note:
>> > 3.5 After dispatching the event, if the event was not cancelled and allowed
>> to bubble, then dispatch an ErrorEvent with the type set to "error" to the
>> Window.
>>
>> You don't need to state "and allowed to bubble", all events dispatched by
>> this algorithm bubble as per step 3.
>>
>
> I'll update the text to say:
> 3.5 After dispatching the event, if the event was not cancelled, then dispatch an ErrorEvent with the type set to "error" to the Window.
>
>> > NOTE: When constructing an IDBVersionChangeEvent you need to follow
>> the same steps defined in DOM4 Section 4.3 Constructing events.  In
>> addition, setting the onerror event handler with window.addEventListener
>> will return the ErrorEvent.  However, setting the onerror event handler with
>> window.onerror will return three arguments as specified in HTML5 spec:
>> event, source, and lineno [1].
>>
>> I agree with Anne, this language is confusing. Dispatch of the onerror handler
>> is handled by the HTML5 so I'm not sure we need to say anything here.
>>
>
> Makes sense!
>
>> > Sample code on how to use the event constructor:
>> > var myDictionary = { canBubble: true, cancellable: true, oldVersion=1,
>> > newVersion=2}; var changeEvent = new
>> > IDBVersionChangeEvent("versionchange", myDictionary);
>>
>
> 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);
>
>> Per [1] you should change 'canBubble' to 'bubbles'.
>>
>> [1] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#eventinit
>>
>> / Jonas
>
> Cool, I will work with Eliot to update the spec.

Awesome, thanks!

/ Jonas
Received on Thursday, 22 September 2011 01:14:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT