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 to fire.
Other specs therefore *may* define when they think it should fire.
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?
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.
* "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.
* "These events should not bubble, and can be canceled." -> "Theseevents
must 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.
* I think initProgressEvent and initProgressEventNS should just defer to
initEvent and initEventNS for details on multiple invocations (in case
that 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 am not
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.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
