- From: Jim Ley <jim@jibbering.com>
- Date: Sun, 28 Jan 2007 12:23:38 -0000
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "Web APIs WG" <public-webapi@w3.org>
"Ian Hickson" <ian@hixie.ch> >> > Could you elaborate on this backwards compatibility problem? >> >> Sure, if authors go >> >> .post() -> update UI to indicate something's started happening >> event.onprogress -> indicate progress >> event.onprogress (complete) -> update UI to indicate things have finished >> >> Then user agents which do not get progress events never see the complete >> status reflected in the UI, however if the UI uses onload to indicate >> things have finished then the script is compatible with images and XHR >> in user agents today. > > Oh I'm not suggesting we get rid of the 'load' event. Never did I think you were. > If authors chose to > only target newer UAs that's an authoring problem, not a backwards > compatibility problem. But then authors can always make that kind of > mistake with new features. The only way to avoid the mistake, is to have everything you do onprogress (complete) also done in onload, there's no other way. If there was a use case where you wish to do something between the 2 events then I've not managed to come up with it. Remember I'm also only suggesting that MUST is too strong a restriction - basically I'd've SHOULD'd your MUST's and MAY'd your SHOULD's. > All I'm saying is that we should make the progress events useful enough > that you can make the entire progress UI updating with them (setting max > and value each time), instead of having to have three sets of code (one to > set the max, one to set the value, and one to set the 100% value). You just agreed that authors will make mistakes if they do that, and given that it's one line of code for people who want your behaviour in onload, I believe it is far and away the easiest solution for authors. The line of code is of course just dispatching the progress event that you want. > So long as we have good examples, showing the progress UI be enabled > before the events, updated by the events, then removed by the handler for > the existing 'load' event, we can easily foster backwards-compatible UI > that will work identically in old and new UAs with the exception of having > nice updating progress bars in the new UAs. So you're relying on "examples" to change author behaviour - I believe that has failed scripters to date and the WG is not chartered to create extensive user tutorial material nor should it be the place. I do not believe it's a sensible requirement when there are no use cases identified when getting that full event. Cheers, Jim.
Received on Sunday, 28 January 2007 12:23:50 UTC