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

Re: Progress event spec

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 28 Jan 2007 07:55:29 +0000 (UTC)
To: Jim Ley <jim@jibbering.com>
Cc: Web APIs WG <public-webapi@w3.org>
Message-ID: <Pine.LNX.4.62.0701280750040.21318@dhalsim.dreamhost.com>

On Sun, 28 Jan 2007, Jim Ley wrote:
> > 
> > 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. 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.

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).

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 28 January 2007 07:55:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:56 GMT