Re: XMLHttpRequest progress events

Robin Berjon wrote:
> Have you considered being compatible (if only by subset) with SVG Tiny 
> 1.2 progress events?
> 
>   http://www.w3.org/TR/SVGMobile12/interact.html#EventsLoadProgress
>   http://www.w3.org/TR/SVGMobile12/svgudom.html#events::ProgressEvent

No, for several reasons:

1)  I don't plan to implement namespaced events in Gecko to support this
     functionality.
2)  Even if we already had namespaced events, it doesn't make much sense to fire
     events in the SVG namespace for XMLHttpRequest, imo.
3)  The actual event dispatched doesn't implement the ProgressEvent interface
     you link to (though this could probably be changed; it could implement that
     in addition to the LSProgressEvent interface it already implements).

> If you don't have any specific reasons for picking those event names, it 
> would likely be best to have just the one name.

Well, the main reason to pick them is that it's consistent with the event we 
currently dispatch to the one listener registered by setting the "onprogress" 
property.  It sorta makes sense that an "onprogress" property corresponds to a 
"progress" event, at least to web authors who're used to "onload" corresponding 
to "load", etc.  While we're not likely to change the "onprogress" property, we 
could name the event something else if needed; see below.

>> Does this seem acceptable?  If not, are there counter-proposals?
> 
> I'm not sure what (and who) exactly you're asking here :)

I'm asking the WG whether it's acceptable to them for us to add these events in 
the null namespace for XMLHttpRequest or whether that conflicts with planned 
work on the part of the WG or with the XMLHttpRequest implementations of other 
participants of the WG.  I realize that you guys may not know what you're 
planning to standardize in version 2, and I'm not proposing we add progress 
events to version 1, but if there _are_ concrete plans to add progress events to 
version 2, I might as well implement those now.

If there aren't, I'll just implement what I feel like and then if progress 
events are brought up in version 2 I'll likely try to get our implementation to 
be the spec.  ;)

So I'm not asking the WG to sanction this implementation decision, but I'm 
asking whether any of the WG members can think of obvious reasons this is a bad 
idea in terms of where they want to take the spec or in terms of interaction 
with their implementations.

-Boris

Received on Sunday, 23 April 2006 23:44:05 UTC