On Sun, 28 Jan 2007 14:11:11 -0500, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
On Sun, 28 Jan 2007 19:49:06 +0100, Charles McCathieNevile
<[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] Try Opera 9.1 http://opera.com
