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 14:31:22 -0500
To: "Anne van Kesteren" <annevk@opera.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmvpukqkwxe0ny@widsith.local>

On Sun, 28 Jan 2007 14:11:11 -0500, Anne van Kesteren <annevk@opera.com>  

> On Sun, 28 Jan 2007 19:49:06 +0100, Charles McCathieNevile 
> <chaals@opera.com> wrote:
>> ? 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...
> So what's unclear to me is which specification will specify whether this 
> event is dispatched for XMLHttpRequest, <html:link>, <html:script>, 
> <html:object>, <html:embed>, <html:img>, <?xml-stylesheet?>,<svg:style>,  
> <xbl:script>, <xbl:style>, etc.

Ah. This specification doesn't define where it is used, just sets some
expectation of where it might be used. So it makes sense to add a note
suggesting that other specifications say where it may/should be used (or  
although I have explained why I don't think specs should do that).

> It's also unclear to me which specification will specify when this event 
> is dispatched. XHR2 will most likely have the "load" event as well, but 
> does the last "progress" event, if any, dispatch before or after 
> readyState changed to 4?

That's up to XHR, IMHO. We will be lucky if they keep close enough to  
together for v1, although we might be lucky enough...

> I think the only reasonable thing this specification can do is to define 
> the semantics of the events and leave the rest of the details to other 
> specifications. Such as when it's dispatched, if ever. Of course, the 
> specification can give some general guidance on how to do that.

OK, so I think we actually agree.

>>>> 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 Iam  
>> not sure why a spec should say that the event must fire.
> So that you can rely on them as an author. Anyway, as stated above I 
> think this is better left for other specifications to define.

I think that it is a bad enough idea relying on the events as an author  
that we
should say "you should not" in this spec.

>>>>> * 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 dependon
>>>> 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?
> That's a reason not to change how DOM Level 3 Events defines it.

Sure, but whether this spec copies that (so it won't change on the  
that it does there) or references it (so you have to check there first) is  
issue here.



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 19:31:20 UTC

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