[Bug 8552] Remove the Progress Element

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





--- Comment #4 from Maciej Stachowiak <mjs@apple.com>  2009-12-27 01:30:26 ---
(In reply to comment #2)
> 
> Metadata techniques are a way of tying together task and task progress. There
> is no association between task and progress element in the description of
> progress. One is left to assume that the progress is associated with some
> action or another, but nothing to give a precise pairing in the markup. 

Progress indicators in UI are often not associated with a specific task and may
entirely lack a label. That being said, sometimes they do have a label, and it
is a fair point that they should be labelable in a way that e.g. assistive
technologies can recognized. Filed bug 8554. (Although aria-labeledby could
potentially work as well).

> 
> As the progress element is currently defined, it can be treated as a static
> element, as well as a dynamically altered element. In particular, the example
> given about space usage could be a static value, displayed when the page is
> first loaded. 
> 
> If a static element, then, it's only useful if you can pair the progress value
> with whatever task is associated. 

Using a <progress> element for a static effect would be a stylistically poor
use. That would be like putting a progress bar in an application that never
moves (or putting a static progress bar looking thing in a document). At TPAC
some people discussed the fact that the text-based fallback handling for
<progress> adds a lot of complexity while serving a useless use case
(markup-declared progress bar). We tentatively agreed that the text-based
fallback should be removed. This is documented in bug 8152.

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

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

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


(In reply to comment #3)
> 
> I'll have more on meter in another bug, but for now, there's nothing in the
> section that specifically states that the progress element must be dynamically
> altered. Indicating task progress could be a static effect, as well as a
> dynamic one. 
> 

Indeed, I don't think it's the right element to display a static level of task
progress - I am not sure that is a likely use case or that it needs specific
presentation.


-- 
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 01:30:28 UTC