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>  
wrote:

> 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  
must,
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  
define
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  
off-chance
that it does there) or references it (so you have to check there first) is  
the
issue here.

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

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