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