[Bug 8552] Remove the Progress Element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552





--- Comment #7 from Shelley Powers <shelleyp@burningbird.net>  2009-12-27 03:02:26 ---
(In reply to comment #6)
> (In reply to comment #5)
> > > > 
> > > > In addition, there's nothing about accessibility associated with the
> > > > description of the progress bar. In fact, there's an implicit assumption of a
> > > > visual association between progress and task that actually makes it vaguely
> > > > inaccessible. 
> > > 
> > > 
> > > This section describes in detail how the progress element's built-in behavior
> > > maps automatically to ARIA:
> > > 
> > > http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria
> > >
> > 
> > And this example shows how the ARIA roles can be applied to existing elements,
> > they're not specific to having a new element.
> > 
> > http://www.mozilla.org/access/dhtml/progressbar
> 
> Indeed, you can use those to build a custom progress indicator from scratch.
> However, the <progress> element has built-in accessibility behavior without the
> need for explicit ARIA markup. You said "there's nothing about accessibility
> associated with the description of the progress bar" but that's incorrect, it
> is defined to have the same accessibility behavior built-in as would be
> provided by ARIA progressbar markup.
> 

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. However,
existing techniques work now, while as far as we know, there is no user agent
implementation of the browser element. 

Does WebKit support the element?

> > 
> > 
> > > > And since we're talking the web, I'm not sure a progress meter visually needs to reflect the OS.
> > > > I would think that web page designers would prefer a platform agnostic visual effect.
> > > 
> > > As with other elements that are typically rendered as UI controls, I think the
> > > default rendering should match the platform, but styling should be able to
> > > override to give a custom appearance. That gives Web developers the choice.
> > > Some Web developers prefer a custom look for all controls, while others prefer
> > > a platform-native appearance. They have that choice with <input type=button>
> > > and we see things done both ways on the Web.
> > > 
> > 
> > Then it seems to me that we're not really not adding enough new functionality
> > that can't be implemented by existing technologies. 
> 
> We're adding at least one piece of new functionality: the ability to get a
> progress that matches the platform look and feel. There is no way to do that
> with existing Web technologies. We're also providing a convenient way to build
> a common piece of functionality: a progress indicator.
> 
> You could similarly argue that <input type=button> or <input type=text> do not
> add any new functionality, since they can be replicated with custom drawing and
> script. Do you believe those should be removed?
> 
> I would instead take the view that reasonably common UI elements should have
> built-in support. You should not have to resort to custom drawing and  events
> and timers to implement basic UI. Further, having built-in elements makes it
> more likely authors will get accessibility right - since it's built in, there
> is no way to get it wrong and no need to add anything special to work with AT.
> 
> > Where are the use cases for the element?
> 
> 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. 

> I'm sure you have seen many other examples of progress bars, spinners or
> throbbers.
>

Sure, for the last 10-15 years or so. 

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



-- 
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 03:02:28 UTC