W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: New draft of Progress events

From: Charles McCathieNevile <chaals@opera.com>
Date: Sun, 28 Jan 2007 13:49:06 -0500
To: "Anne van Kesteren" <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmvnv42cwxe0ny@widsith.local>

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

> 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,  
course. Or not - this specification exists independently and can be  
without a reference, since it is designed not to require firing anywhere  
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  
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  
like it did yesterday. Hence the issue - what do others think?



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC