[Bug 8552] Remove the Progress Element


--- Comment #5 from Shelley Powers <shelleyp@burningbird.net>  2009-12-27 02:02:34 ---

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


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

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

Where are the use cases for the element?

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:02:36 UTC