Re: New draft of Progress events

On Sun, 28 Jan 2007 13:00:09 -0500, Anne van Kesteren <annevk@opera.com>  
wrote:

> 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 tofire.  
>> Other specs therefore *may* define when they think it shouldfire.  
>> 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?

? I don't understand what you mean here. Specs can require what they like,  
of
course. Or not - this specification exists independently and can be  
implemented
without a reference, since it is designed not to require firing anywhere  
and
allow them where you like...

>> 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.

Maybe not, but for backward compatibility it makes sense to me. And I am  
not
sure why a spec should say that the event must fire.

>>> * "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.

OK, will be like that in the next draft.

>>> * "These events should not bubble, and can be canceled." -> 
>>> "Theseeventsmust 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.

Actually the reasoning you explained on IRC has more weight than you  
trying to
throw your weight behind yourself :) Anyway, agreed - the change will be  
in the
next draft.

>>> * I think initProgressEvent and initProgressEventNS should just defer 
>>> toinitEvent and initEventNS for details on multiple invocations (in 
>>> casethat 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 amnot  
>> 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.

Maybe. On the other hand, maybe you want your implementation to keep  
working
like it did yesterday. Hence the issue - what do others think?

cheers

chaals

-- 
Charles McCathieNevile, Opera Software: Standards Group
hablo español - je parle français - jeg lærer norsk
chaals@opera.com Try Opera 9.1 http://opera.com

Received on Sunday, 28 January 2007 18:49:05 UTC