Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12

On Mon, Apr 25, 2011 at 6:12 PM, Jacob Rossi <jrossi@microsoft.com> wrote:
> I plan on adding wording to D3E to clarify that DOM event propagation could apply to other tree-like structures (like indexedDB objects) [1].
>
> However, I'm not a fan of defining variable behavior for a given event type. Yes, the spec currently does this--but as you accurately point out, just because it was done before doesn't make it right. :-) Most of these inconsistencies in D3E exist to allow for legacy behavior. Take for example, the scroll event (which is the only event in D3E I can think of which has variable bubbling behavior). It's only defined to bubble in certain cases because that's what is (unfortunately) the interoperable behavior.
>
> IMO, I think XHR is wrong to overload error like this. There should be a progresserror event--but I suppose that ship has sailed. Alternatively, DOM3 Events could define an additional event type (with a name other than "error") which does bubble. That way dependent specifications have a choice of which behavior to adopt.
>
> Going forward, I think we should be consistent in defining the interface, bubbling, and cancelling aspects of an event type cross-specifications. We can't correct the world as it is today, but we shouldn't proliferate the discrepancies. I think it's a complicated developer model to have an event bubble only in certain scenarios.

I agree consistency is good, but it comes in many flavors. If the
event was called progresserror for XHR, then that would mean that you
have to listen for "error" in some places but "progresserror" in
others, for what is essentially the exact same thing.

That isn't consistent from a author point of view either.

To make matters worse XHR used to use plain Events, but then gained
the extra feature of reporting progress by adding additional
properties to its various events. So it would have been very messy if
we had tried to restrict "error" to just be plain Events.

If we really feel that we must keep consistent with any events that
DOM Events spec defines, then DOM Events needs to be a lot more
careful about defining events with generic names. Otherwise other
specs have to work around DOM Events by arbitrarily using more complex
names. This doesn't sound like a win for anyone.

/ Jonas

Received on Tuesday, 26 April 2011 17:21:16 UTC