ISSUE-96: Remove/Discard the Progress Element

progress

Remove/Discard the Progress Element

State:
CLOSED
Product:
pre-LC1 HTML 5 spec
Raised by:
Shelley Powers
Opened on:
2010-01-11
Description:
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.

Change Proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/removeprogress

HTML5-SPEC-SECTIONS [the-progress-element]

Related Actions Items:
No related actions
Related emails:
  1. {agenda} HTML WG telecon 2011-03-24: Issues, surveys, decisions (from mjs@apple.com on 2011-03-23)
  2. Working Group Decision on ISSUE-96 progress (from rubys@intertwingly.net on 2011-03-19)
  3. HTML Working Group Status (from plh@w3.org on 2010-08-27)
  4. RE: {minutes} HTML WG telecon 2010-08-19: WG decisions, Decision Policy, TF reports (from adrianba@microsoft.com on 2010-08-19)
  5. {agenda} HTML WG telecon 2010-08-19: WG decisions, Decision Policy, TF reports (from Paul.Cotton@microsoft.com on 2010-08-17)
  6. {agenda} HTML WG telecon 2010-08-12: action 29; issues 116, 30, 109, 27; bugs 9894, 10066 (from rubys@intertwingly.net on 2010-08-11)
  7. RE: {minutes} HTML WG telecon 2010-08-04 [task force week] (from adrianba@microsoft.com on 2010-08-05)
  8. {agenda} HTML WG telecon 2010-08-04 [task force week] (from rubys@intertwingly.net on 2010-08-04)
  9. {minutes} HTML WG telecon 2010-07-29, WG decisions, issue review, WG surveys (from Paul.Cotton@microsoft.com on 2010-07-29)
  10. {agenda} HTML WG telecon 2010-07-29, WG decisions, issue review, WG surveys (from Paul.Cotton@microsoft.com on 2010-07-27)
  11. RE: {minutes} HTML WG telecon 2010-07-22 (from adrianba@microsoft.com on 2010-07-22)
  12. RE: {agenda} HTML WG telecon 2010-07-22 (from eliotgra@microsoft.com on 2010-07-22)
  13. RE: {agenda} HTML WG telecon 2010-07-22 (from krisk@microsoft.com on 2010-07-22)
  14. {agenda} HTML WG telecon 2010-07-22 (from mjs@apple.com on 2010-07-21)
  15. {minutes} HTML WG telecon 2010-07-15 (from Paul.Cotton@microsoft.com on 2010-07-15)
  16. {agenda} HTML WG telecon 2010-07-15: note new dial-in numbers for Paris and London (from rubys@intertwingly.net on 2010-07-14)
  17. {minutes} HTML WG telecon 2010-07-08: actions, issues, decisions, revised proposals, future surveys, TF reports (from Paul.Cotton@microsoft.com on 2010-07-08)
  18. FW: {agenda} HTML WG telecon 2010-07-08: actions, issues, decisions, revised proposals, future surveys, TF reports (from Paul.Cotton@microsoft.com on 2010-07-07)
  19. {agenda} HTML WG telecon 2010-07-08: actions, issues, decisions, revised proposals, future surveys, TF reports (from Paul.Cotton@microsoft.com on 2010-07-07)
  20. RE: {agenda} HTML WG telecon 2010-07-01: issues, surveys, decisions, publication status, TF reports (from Paul.Cotton@microsoft.com on 2010-06-30)
  21. {agenda} HTML WG telecon 2010-07-01: issues, surveys, decisions, publication status, TF reports (from mjs@apple.com on 2010-06-30)
  22. {minutes} } HTML WG telecon 2010-07-24: issues, surveys, decisions, publication status, TF reports (from Paul.Cotton@microsoft.com on 2010-06-25)
  23. Fwd: {agenda} HTML WG telecon 2010-07-24: issues, surveys, decisions, publication status, TF reports (from rubys@intertwingly.net on 2010-06-23)
  24. {minutes} HTML WG telecon 2010-06-10: action items, decision policy, task force reports, publication status (from adrianba@microsoft.com on 2010-06-10)
  25. Re: {agenda} HTML WG telecon 2010-06-10: action items, decision policy, task force reports, publication status (from laura.lee.carlson@gmail.com on 2010-06-10)
  26. FW: {agenda} HTML WG telecon 2010-06-10: action items, decision policy, task force reports, publication status (from Paul.Cotton@microsoft.com on 2010-06-10)
  27. {agenda} HTML WG telecon 2010-06-10: action items, decision policy, task force reports, publication status (from Paul.Cotton@microsoft.com on 2010-06-10)
  28. {agenda} HTML WG telecon 2010-06-03 (from rubys@intertwingly.net on 2010-06-02)
  29. RE: {agenda} HTML WG telecon 2010-05-27 (from adrianba@microsoft.com on 2010-05-27)
  30. Re: {agenda} HTML WG telecon 2010-05-27 (from faulkner.steve@gmail.com on 2010-05-27)
  31. Re: {agenda} HTML WG telecon 2010-05-27 (from laura.lee.carlson@gmail.com on 2010-05-27)
  32. {agenda} HTML WG telecon 2010-05-27 (from rubys@intertwingly.net on 2010-05-26)
  33. {agenda} HTML WG telecon 2010-05-20: Surveys close, Publishing new Working Drafts (from mjs@apple.com on 2010-05-19)
  34. ISSUE-96 implementation experience (from shelleyp@burningbird.net on 2010-05-15)
  35. minutes, 2010-05-13 HTML WG telcon (from mike@w3.org on 2010-05-14)
  36. World-readable issue survey results (from mjs@apple.com on 2010-05-13)
  37. {agenda} HTML WG telecon 2010-05-13: Action items, surveys, Task Force reports (from mjs@apple.com on 2010-05-12)
  38. ISSUE-96 - Removing the progress Element - Straw Poll for Objections (from mjs@apple.com on 2010-05-12)
  39. RE: {agenda} HTML WG telcon 2010-05-06: Action items, issues, decision policy, calls, surveys, publishing - minutes (from adrianba@microsoft.com on 2010-05-06)
  40. {agenda} HTML WG telcon 2010-05-06: Action items, issues, decision policy, calls, surveys, publishing (from rubys@intertwingly.net on 2010-05-05)
  41. HTML-A11Y Task Force Recommendation: ISSUES-90, 91, 93, 95, 96, & 97 (from janina@rednote.net on 2010-05-03)
  42. RE: {agenda} HTML WG telcon 2010-04-29: Action items, new issues, Task Force reports - minutes of the meeting (from adrianba@microsoft.com on 2010-04-29)
  43. {agenda} HTML WG telcon 2010-04-29: Action items, new issues, Task Force reports (from mjs@apple.com on 2010-04-28)
  44. Re: Zero-edit Change Proposal for ISSUE-90 figure, ISSUE-91 aside, ISSUE-93 details, ISSUE-95 hidden, ISSUE-96 progress, and ISSUE-97 meter (from mjs@apple.com on 2010-04-21)
  45. {agenda} HTML WG telcon 2010-04-22: Action items, issues, decision policy, A11Y recommendations, polyglot spec (from Paul.Cotton@microsoft.com on 2010-04-21)
  46. {agenda} HTML WG telcon 2010-04-22: Action items, issues, decision policy, A11Y recommendations, polyglot spec (from Paul.Cotton@microsoft.com on 2010-04-21)
  47. Fwd: HTML-A11Y Task Force Recommendation: ISSUES-90, 91, 93, 95, 96, & 97 (from rubys@intertwingly.net on 2010-04-21)
  48. Minutes of HTML WG meeting, Apr 8 2010 (from Paul.Cotton@microsoft.com on 2010-04-08)
  49. {agenda} HTML WG telcon 2010-04-08: calls for proposals, issue status (from mjs@apple.com on 2010-04-07)
  50. Re: ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95, ISSUE-96, ISSSUE-97: (new semantic elements/attributes) - Chairs Solicit Alternate Proposals or Counter-Proposals (from mjs@apple.com on 2010-04-06)
  51. Fwd: native elements versus scripted (from shelley.just@gmail.com on 2010-04-06)
  52. Re: native elements versus scripted (from jonas@sicking.cc on 2010-04-06)
  53. Re: ISSUE-96 Change Proposal (from mjs@apple.com on 2010-04-06)
  54. native elements versus scripted (from shelley.just@gmail.com on 2010-04-06)
  55. Re: Removal of other semantic elements (from jonas@sicking.cc on 2010-04-04)
  56. Re: Removal of other semantic elements (from shelley.just@gmail.com on 2010-04-04)
  57. Re: Removal of other semantic elements (from faulkner.steve@gmail.com on 2010-04-04)
  58. Re: Removal of other semantic elements (from shelley.just@gmail.com on 2010-04-02)
  59. Re: Removal of other semantic elements (from shelley.just@gmail.com on 2010-04-02)
  60. Re: Removal of other semantic elements (from mjs@apple.com on 2010-04-02)
  61. RE: Removal of other semantic elements (from jfoliot@stanford.edu on 2010-04-02)
  62. Removal of other semantic elements (from jonas@sicking.cc on 2010-04-02)
  63. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  64. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  65. RE: ISSUE-96 Change Proposal (from jfoliot@stanford.edu on 2010-04-01)
  66. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  67. RE: ISSUE-96 Change Proposal (from jfoliot@stanford.edu on 2010-04-01)
  68. Re: ISSUE-96 Change Proposal (from joshue.oconnor@cfit.ie on 2010-04-01)
  69. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  70. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  71. Re: ISSUE-96 Change Proposal (from mjs@apple.com on 2010-04-01)
  72. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  73. RE: ISSUE-96 Change Proposal (from jfoliot@stanford.edu on 2010-04-01)
  74. Re: ISSUE-96 Change Proposal (from faulkner.steve@gmail.com on 2010-04-01)
  75. Re: ISSUE-96 Change Proposal (from joshue.oconnor@cfit.ie on 2010-04-01)
  76. Re: ISSUE-96 Change Proposal (from joshue.oconnor@cfit.ie on 2010-04-01)
  77. Re: ISSUE-96 Change Proposal (from mjs@apple.com on 2010-04-01)
  78. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  79. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  80. Re: ISSUE-96 Change Proposal (from schepers@w3.org on 2010-04-01)
  81. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  82. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  83. Re: Mouse-less browsing/Datepicker (was RE: ISSUE-96 Change Proposal) (from jonas@sicking.cc on 2010-04-01)
  84. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  85. Mouse-less browsing/Datepicker (was RE: ISSUE-96 Change Proposal) (from jfoliot@stanford.edu on 2010-04-01)
  86. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  87. Re: ISSUE-96 Change Proposal (from mattmay@adobe.com on 2010-04-01)
  88. Re: ISSUE-96 Change Proposal (from mjs@apple.com on 2010-04-01)
  89. [minutes] 2010-04-01 HTML Teleconference (from rubys@intertwingly.net on 2010-04-01)
  90. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  91. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  92. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  93. Re: ISSUE-96 Change Proposal (from brucel@opera.com on 2010-04-01)
  94. Re: ISSUE-96 Change Proposal (from mjs@apple.com on 2010-04-01)
  95. Re: ISSUE-96 Change Proposal (from faulkner.steve@gmail.com on 2010-04-01)
  96. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  97. Re: ISSUE-96 Change Proposal (from faulkner.steve@gmail.com on 2010-04-01)
  98. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  99. Re: ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-04-01)
  100. Re: ISSUE-96 Change Proposal (from jonas@sicking.cc on 2010-04-01)
  101. Re: Change proposals uploaded to Wiki - URLs, suggestions on Issue 92 table (from mjs@apple.com on 2010-03-31)
  102. ISSUE-96 Change Proposal (from shelley.just@gmail.com on 2010-03-31)
  103. Re: {agenda} HTML WG telcon 2010-04-01: action items, decision policy update, issue status (from shelley.just@gmail.com on 2010-03-30)
  104. {agenda} HTML WG telcon 2010-04-01: action items, decision policy update, issue status (from Paul.Cotton@microsoft.com on 2010-03-30)
  105. {agenda} HTML WG telcon 2010-04-01: action items, decision policy update, issue status (from Paul.Cotton@microsoft.com on 2010-03-30)
  106. [minutes] 20100325 HTML teleconference (from plh@w3.org on 2010-03-30)
  107. Re: {agenda} HTML WG telcon 2010-03-25: decision policy, issue status, updates from meetings, task force reports (from mjs@apple.com on 2010-03-24)
  108. {agenda} HTML WG telcon 2010-03-25: decision policy, issue status, updates from meetings, task force reports (from rubys@intertwingly.net on 2010-03-24)
  109. Re: Breakdown of issues (from rubys@intertwingly.net on 2010-03-12)
  110. Breakdown of issues (from mjs@apple.com on 2010-03-12)
  111. Re: ISSUE-93 details - Call for Change Proposals (from mjs@apple.com on 2010-01-27)
  112. {agenda} HTML WG telcon 2010-01-28: (from mjs@apple.com on 2010-01-27)
  113. Re: RETRACTION: ISSUE-98 canvas2d - Call for Change Proposals (from shelley.just@gmail.com on 2010-01-27)
  114. ISSUE-96 progress - Call for Change Proposals (from Paul.Cotton@microsoft.com on 2010-01-26)
  115. RETRACTION: ISSUE-98 canvas2d - Call for Change Proposals (from Paul.Cotton@microsoft.com on 2010-01-26)
  116. Re: {agenda} HTML WG telcon 2010-01-14: AIs, CfC/CfPs, TFs, plus: heartbeat docs (from shelley.just@gmail.com on 2010-01-13)
  117. {agenda} HTML WG telcon 2010-01-14: AIs, CfC/CfPs, TFs, plus: heartbeat docs (from rubys@intertwingly.net on 2010-01-13)
  118. [Bug 8552] Remove the Progress Element (from bugzilla@wiggum.w3.org on 2010-01-11)
  119. ISSUE-96 (progress): Remove/Discard the Progress Element [HTML 5 spec] (from sysbot+tracker@w3.org on 2010-01-11)

Related notes:

Change Proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/removeprogress

Laura Carlson, 10 May 2010, 13:08:50

Changelog:

Created issue 'Remove/Discard the Progress Element' nickname progress owned by Shelley Powers on product HTML 5 spec, description '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.



' non-public

Shelley Powers, 11 Jan 2010, 15:45:09

Status changed to 'open'

Sam Ruby, 12 Feb 2010, 20:21:30

Description changed to '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.

HTML5-SPEC-SECTIONS [the-progress-element]

'

Shelley Powers, 12 Feb 2010, 23:47:39

Description changed to '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.

Change Proposal:
http://www.w3.org/html/wg/wiki/ChangeProposals/removeprogress

HTML5-SPEC-SECTIONS [the-progress-element]

'

Laura Carlson, 10 May 2010, 13:08:50

Product changed to pre-LC1 HTML 5 spec

Sam Ruby, 29 Jan 2011, 18:22:25

Status changed to 'closed'

Sam Ruby, 19 Mar 2011, 14:25:44


Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Chairs, Michael[tm] Smith <mike@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.323 2013-12-19 14:47:09 dom Exp $