ISSUE-96 (progress): Remove/Discard the Progress Element [HTML 5 spec]

ISSUE-96 (progress): Remove/Discard the Progress Element [HTML 5 spec]

http://www.w3.org/html/wg/tracker/issues/96

Raised by: Shelley Powers
On product: HTML 5 spec

The progress element is to be use to mark the progress of a specific task, but
there is no way to easily differentiate what the task is. Automations would be
reduced to scraping the page and attempting to derive the task based on page
structure, rather than based on sound semantic principle.

There are metadata approaches to marking up both task, and its associated
progress. People can use RDFa to mark both, using sound and tested techniques.
With the use of RDFa, applications won't need complicated and error-prone
algorithms to try and derive the task-progress pair. In addition, people can
also use Microformats, either with existing Microformat vocabularies, or ones
to be introduced into the future. 

A further reason to no longer keep the progress element is that there's nothing
associated with the progress element that will make web application developer
tasks any easier. It's just as simple to use existing progress indicator
functionality built into existing JavaScript, Canvas, and SVG libraries, as it
would be to use this element. If anything, the use of this element could
require more work, in order to change existing libraries to use a specific type
of element, rather than the more general div or span elements most likely used
today. 

The addition of a progress element will also require modification to HTML
editors, as well as browsers, and as far as I've been able to determine, other
than using it more or less as an unknown element, there is no implementation
for this element. 

Lastly, the description for progress is overly complicated--mixing HTML syntax
and user agent parsing directions, as well as proving an inordinate number of
somewhat confusing rules and regulations for the progress element's conforming
use. This is going to make it more likely, rather than less, that the progress
element will be used by web page authors and designers correctly. 

It would be best to remove the element, and depend on existing semantic markup
techniques, such as RDF and Microformats to mark up semantics, and existing
JavaScript libraries and graphics capabilities such as Canvas, CSS, and SVG, to
provide presentation.

The editor has stated that creation of Progress was specifically because of accessibility. However, there is nothing specific to this element that makes it any more accessible than the implementations already in existence. Both the Progress element and the existing implementations all require JavaScript, and all update DOM elements. Both have a strongly visual element to them. All the Progress element does is attach a system specific interface. In fact, it's purpose is specifically to provide a system specific interface--it can't styled any other way. 

I believe this element was originally created for web applications to emulate desktop applications in appearance. However, most web applications have their own look and feel, and aren't interested in having their apps look like a native app. There's even some inherent risk in doing so (with a web app pretending to be a native app). This means that the applications that want to have their own look, will have to use alternative methods, anyway.

Received on Monday, 11 January 2010 15:45:10 UTC