[Bug 8552] Remove the Progress Element

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





--- Comment #6 from Maciej Stachowiak <mjs@apple.com>  2009-12-27 02:33:07 ---
(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.

> 
> > > 
> > > Currently now, if we use images of some form to indicate specific progress, we
> > > can use alt text and other techniques (such as RDF or RDFa in SVG) to provide a
> > > textual description of the progress. 
> > > 
> > > In addition, there's nothing about the element description that indicates it
> > > provides a platform specific visual element.
> > 
> > http://dev.w3.org/html5/spec/Overview.html#the-progress-element-0 
> > 
> > "User agents are expected to use a presentation consistent with platform
> > conventions for progress bars. In particular, user agents are expected to use
> > different presentations for determinate and indeterminate progress bars. User
> > agents are also expected to vary the presentation based on the dimensions of
> > the element."
> >
> 
> That's mighty vague.

You previously said: "In addition, there's nothing about the element
description that indicates it provides a platform specific visual element."
That's clearly incorrect. It's true that the requirement is stated in a vague
way, because platform conventions for progress indicators vary widely.

> And again, I don't think it's necessarily a valid approach
> for web applications. Do web designers want a platform specific visual display,
> or one that's consistent across all platforms? The latter has traditionally
> been the favored approach with web pages and web applications. 

Web applications always use a custom look for progress bars, because there
hasn't been a way to get the platform native look. For text fields, scrollbars
or checkboxes, it's most common to use the platform look, and it's easy to do.
For pusbuttons, both approaches (platform-native and custom) are quite common.

Your own preference may be for all custom controls in Web apps - but clearly
not all Web designers agree. I don't think it makes sense to call one approach
or the other "invalid".

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

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


-- 
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 02:33:09 UTC