W3C home > Mailing lists > Public > public-webapi@w3.org > January 2007

Re: Progress event spec

From: Jim Ley <jim@jibbering.com>
Date: Sun, 28 Jan 2007 12:23:38 -0000
Message-ID: <010b01c742d7$24975d90$406e11ac@Sniff>
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.


Received on Sunday, 28 January 2007 12:23:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:22 UTC