On Sun, 28 Jan 2007 13:00:09 -0500, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
On Sun, 28 Jan 2007 18:51:49 +0100, Charles McCathieNevile
<[EMAIL PROTECTED]> wrote:
* The specification should make it clear that other specifications must
define when it is to be dispatched. (This should be also be made clear
for the examples.)
Sure, but my current approach to ISSUE-106 is that it never has tofire.
Other specs therefore *may* define when they think it shouldfire.
Otherwise user agents can just fire it as they please during
asynchronous network operations.
Whether or not specifications require it to fire is independent of who
makes the requirements regarding firing, no?
? 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...
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.
* "The user agent may dispatch a progress event while an asynchronous
network opertation such as a load event is taking place." doesn't make
much sense to me.
apart from the typo, and changing "load event" (which I meant there in
the everyday sense of 'occurrence' but which is probably really
confusing) to "load operation", is there anything you can suggest to
make it clearer?
That would make it more clear.
OK, will be like that in the next draft.
* "These events should not bubble, and can be canceled." ->
"Theseeventsmust not bubble and most be cancelable."
must be cancelable - agreed. Not sure that we should be upset if some
user agent does allow them to bubble, although since they should not
authors relying on it are a bit mad. Anyone else want to throw their
weight behind
must not bubble?
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.
* 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?
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
