W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2009

[Bug 8552] Remove the Progress Element

From: <bugzilla@wiggum.w3.org>
Date: Sun, 27 Dec 2009 07:58:46 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NOo1W-00071L-KU@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552





--- Comment #8 from Maciej Stachowiak <mjs@apple.com>  2009-12-27 07:58:46 ---
(In reply to comment #7)

> 
> Six of one, half dozen of another -- I have a feeling the same amount of work
> is required with the custom work as it is with the progress element.

I don't think that's the case. With a fully custom control, you have to handle
the appearance, behavior (responding to the API and possibly including
animations), and the accessibility via ARIA. Then you poke at that API. With
the <progress> element, the first three are taken care of for you, so you just
go ahead and use the API. If you want custom appearance, then you must provide
for that, but

> However, existing techniques work now, while as far as we know, there is no user agent
> implementation of the browser element. 

This is true for most of the new elements - until they get implemented.

>
> Does WebKit support the element?

Not yet, but it's definitely on our wishlist. For now we are holding off until
bug 8152 gets addressed. See some of our earlier feedback here:

http://lists.w3.org/Archives/Public/public-html/2009Sep/0008.html


> > 
> > I think the use cases for a progress indicator are pretty obvious, but here
> > goes:
> > 
> > - Displaying progress of a slow computation happening on a background thread.
> > - Displaying an indefinite duration "busy" state.
> > - Indicating the progress of a network upload or download.
> > - Indicating the time it will take an application to launch via a splash
> > screen.
> > - Showing the progress of a copy operation.
> > 
> 
> Part of these could be replaced by a generic throbber graphic, as is widely
> implemented today. 
> 
> However, I'm not sure we have all the pieces in place to actually use a
> progress element with things like network uploads and downloads, because we
> don't always have the access to the data in order to programatically update the
> progress bar to reflect the state. 

XMLHttpRequest2 supports Progress Events for both upload and download, and the
HTML5 media elements support it for download. These are some of the more likely
APIs to be used for large transfers. Likely more APIs will have progress event
support added.


> We disagree. Luckily there's a procedure in place to handle disagreement. 

Fair enough. It just seemed like your original suggestion was based on some
incorrect assumptions about the spec. I just wanted to set the record straight
on those, to make sure we have the correct information on the record. If none
of this changes your mind, so be it.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 27 December 2009 07:58:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:43 UTC