- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 Oct 2011 18:13:25 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> 1. Make "loadend" not fire in case a new load is started from >> onabort/onload/onerror. Thus "loadend" and "loadstart" isn't always >> paired up. Though there is always a "loadend" fired after every >> "loadstart". >> 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also >> >> leaves the problem unsolved for XHR. >> >> Are there other options I'm missing? > > Or do both, improving XHR as much as backwards-compatibility allows and > don't try to match other APIs to it exactly. I'd much prefer weirdness be > isolated to XHR than be perpetuated through every PE-based API. So what exactly are you proposing we do for XHR and for FileReader/FileWriter? I'm still not convinced that it's better for authors to require them to use setTimeout to start a new load as opposed to let them restart the new load from within an event and cancel all following events. I agree that this introduces some inconsistency, but it only does so when authors explicitly reuses a FileReader/XHR/FileWriter for multiple requests. And it only weakens the invariant, not removes it. So instead of * There's exactly one 'loadend' event for each 'loadstart' event. we'll have * There's always a 'loadend' event fired after each 'loadstart' event. However there might be other 'loadstart' events fired in between. / Jonas / Jonas
Received on Tuesday, 4 October 2011 01:14:22 UTC