Re: New draft of Progress events

On Sun, 28 Jan 2007 18:51:49 +0100, Charles McCathieNevile  
<chaals@opera.com> wrote:
>> * The specification should make it clear that other specifications must 
>> define when it is to be dispatched. (This should be also be made clear 
>> for the examples.)
>
> Sure, but my current approach to ISSUE-106 is that it never has to fire.  
> Other specs therefore *may* define when they think it should fire.  
> Otherwise user agents can just fire it as they please during  
> asynchronous network operations.

Whether or not specifications require it to fire is independent of who  
makes the requirements regarding firing, no?


> IMHO authors should never rely on it firing, primarily because if they  
> do then they break backpat for no particularly good reason that I can  
> see. So specs *should not* say it *must* fire...

I'm not sure this makes much sense in the long term.


>> * "The user agent may dispatch a progress event while an asynchronous 
>> network opertation such as a load event is taking place." doesn't make 
>> much sense to me.
>
> apart from the typo, and changing "load event" (which I meant there in  
> the everyday sense of 'occurrence' but which is probably really  
> confusing) to "load operation", is there anything you can suggest to  
> make it clearer?

That would make it more clear.


>> * "These events should not bubble, and can be canceled." -> "Theseevents 
>> must not bubble and most be cancelable."
>
> must be cancelable - agreed. Not sure that we should be upset if some  
> user agent does allow them to bubble, although since they should not  
> authors relying on it are a bit mad. Anyone else want to throw their  
> weight behind
> must not bubble?

Yes, me. Interoperability is important.


>> * I think initProgressEvent and initProgressEventNS should just defer to 
>> initEvent and initEventNS for details on multiple invocations (in case 
>> that changes at some point).
>
> I think once we put the spec out, making this particular part depend on
> something that might change later doesn't help interoperability, so I  
> would prefer we define what happens here and stick with it. But I am not  
> particularly wedded to that. I've raised ISSUE-111.

If there was a good reason for the change surely you want all those  
methods to behave the same way.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Sunday, 28 January 2007 18:00:23 UTC