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

Re: New draft of Progress events

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 28 Jan 2007 20:11:11 +0100
To: "Charles McCathieNevile" <chaals@opera.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmvowxgo64w2qv@id-c0020.nomadprime.subscribe.loganwifi.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.

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?

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.


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

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.


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

Sorry for assuming the consequences were known. For the record:

   <object onprogress="..."> <img> </object>

... would do very different things dependong on whether or not you let the  
progress event bubble. (Björn came up with this particular example.)


>>>> * 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?

That's a reason not to change how DOM Level 3 Events defines it.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Sunday, 28 January 2007 19:11:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT