The decision follows. The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.
*** Question before the Working Group ***
There is a basic disagreement in the group as to whether or not the
HTML5 language should include a progress element. The result was an
issue, two change proposals, and a straw poll for objections:
http://www.w3.org/html/wg/tracker/issues/96http://lists.w3.org/Archives/Public/public-html/2010Nov/0234.htmlhttp://lists.w3.org/Archives/Public/public-html/2011Jan/0356.htmlhttp://www.w3.org/2002/09/wbs/40318/issue-96-objection-poll/results
== Uncontested observations:
* Each new element, attribute, and control is extra functionality for
browsers to implement, and for HTML educators, including tutorials,
to teach.
* The default styling for this element is likely to be platform
specific. No mechanism has been defined to override this styling.
Neither of these were decisive. There were people who supported either
of the change proposals even after taking these facts into
consideration. The fact that they were acknowledged up front was
appreciated.
== Positive Effects
The following is listed as the positive effect for removing the
progress element:
Removes another new element in the rather large pool of new HTML5
elements. This reduces the burden on all user agents, including
browsers, editors, and so on. It's important for the HTML WG not to
introduce new elements that are redundant considering the state of
supporting technologies today, such as CSS for styling, JavaScript for
behavior, and ARIA for both semantics and accessibility (and even
Canvas and SVG, if we want to get fancy with graphics). We shouldn't
be creating single-purposed elements unless there is no existing
functionality that can serve the purpose of the element, and that's
definitely not true with progress bars.
This is fundamentally a statement on behalf of others who are capable of
speaking for themselves. And many of them did. Quotes below. First
up, authors:
The "HTML5 Superfriends" group of Web standards experts supports the
<progress> element, demonstrating support in the authoring community.
reduce the need to use javascript libraries or build your own
javascript code for it, at the same time making sure accessibility is
provided. Less javascript will make web page display more efficient.
Many operating systems have a very specific platform-native look for
progress indicators. While some content authors want to make web
applications with custom-looking controls for everything, others want
to match the platform native look. Often they try to do this by
building controls out of image pieces in the hopes of targeting a
single platform, causing a mismatch on other platforms or when the
original target platform changes. The <progress> element is the only
proposed way to get a progress indicator with a truly native look and
feel.
My experience working with web authors for several years is that they
tend to do what is easy, whereas accessibility often ends up coming
second due to time constraints and unawareness.
Implementors:
The <progress> element has an initial experimental implementation in
WebKit. Implementation experience shows that it is useful and
beneficial.
Implementors of other browser engines, including Gecko and Presto,
have expressed interest in implementing this element.
Progress indicators are one of the basic control types supported on
both Mac OS X and iPhone OS. They are part of a complete modern UI
toolkit. HTML5 should serve applications by providing a complete set
of fundamental controls.
Language designers:
Progress indicators are a common and useful UI idiom in a wide range
of native applications. HTML5 should serve this idiom directly.
HTML was designed as a language for describing documents, but it is
being used as a language for building user interface. As such, it is
missing many of the primatives needed for user interface. This has
caused authors to build their own interface elements, each slightly
different, and many missing quality requirements (including
accessibility). To advance high quality, consistent web-based
applications, we need to move as many of these as possible into HTML
and into browsers. These elements with built-in behavior are one of
the most important advances in HTML 5, and must be retained.
I think it's very unlikely that as many people would add proper ARIA
attributes, as would use the <figure> element. I think this is the
reason that the WAI-ARIA specification encourages developers of markup
languages to add semantic elements and explicitly declares ARIA as a
bridge technology. I also think this is why the HTML Accessibility TF
has endorsed the <figure> element.
While some of these quotes are also statements made on behalf of others
-- and thereby effectively cancelling out equivalent unsubstantiated
assertions -- others clearly are made by people directly involved.
These statements indicate that this element addressed a know use case,
has people willing to implement the functionality in major browsers,
and has people who plan to make use of the functionality once it ships.
Taken together, we find that there is substantial support in the group
for the progress element, and this shifts the burden of proof. It would
therefore take a strong objection to cause the element to be removed.
=== Objections
At this point we have established substantial support for the progress
element, and therefore the objection to removing the <progress> element
"as it would result in missing out of the positive effects listed" is
found to be substantial. As such we turn to the objections expressed
on the "Change Proposal to Keep New Elements and Attributes" to see if
there are any which are as strong or stronger than this objection.
In the below, representative samples of the objections which were put
forth are quoted and then evaluated. The full quotes can be found in
the URIs at the top of this decision.
-- Risk and lack of transition plans:
I'm not *strongly* opposed to the concepts that these semantic
elements, attributes and controls add, but I do think that, in order
to actually reach a W3C standard quickly, controversial additions that
are likely to slow down progress or result in poor interoperability
should be removed from the specification so that the W3C HTML working
group can reach closure quickly.
One thing that concerns me about many of these is that the transition
plan is unclear to me: how can authors can introduce these new
features and still be compatible with older browsers? Without a clear,
acceptable transition plan, the risk is to fragment the web, and to
encourage authors to create "best viewed by HTML5" web sites, in a
repeat of Browser Wars 1.0. The current specification does not address
the transition and fallback issues, and for that reason alone, these
elements should be removed until those details can be worked out and
reviewed fully.
This is a self-admitted weak objection, entirely lacking in specifics.
It suggests that this element be removed speculatively based on the
possibility that there might someday be found a problem with
interoperability or transition fallbacks.
-- Accessibility has not been vetted:
If the task force does not have an official and trackable plan, the
time, or the volunteers to fulfill their commitment, the figure and
figcaption elements should be dropped from the spec.
Despite the explicit endorsement by the A11y Task Force, once again we
have a request that this element be speculatively removed based on the
possibility of a problem in the future.
-- Lack of implementation.
The progress element currently lacks implementation in browsers and
assistive technology... if the conventional Web browser is challenged
in rendering a Web content, the challenge will pass on to the
assistive technology. In the end, if the behavior is unpredictable it
may be unusable.
Once again, a request that this element be speculatively removed based
on the possibility of a problem in the future.
-- Lack of styling.
Native elements that are not styleable to suit the aesthetic desires
of developers and marketing departments will not be used. Elements
that are not used are not needed in the spec. They are excess
baggage. Default rendering and graceful degradation are unknown.
This is a combination of an assertion on behalf of others, and a
request that this element be removed based on unknown and unspecified
problems. Meanwhile, we have received statements that indicate that
this element will be used.
-- Unknown implications of progress being a form element.
The progress element is currently a form element. It is unknown what
happens if the progress element is actually added to a form. It is
not specified if the current value is sent with other form element
values to the server application or if it isn't.
Once again, a request that this element be speculatively removed based
on the possibility of a problem.
-- Behavioral user interface elements present a layering violation.
I have always used the three legged stool approach to web
standards... If behavior is not well thought out, it can be a
disaster.
This is an assertion of a design goal over which we have not previously
found there to be consensus in the working group. We have others that
find this very same element to be semantic, and firmly believe that
semantic elements lead to improved accessibility. Furthermore, the HTML
WG Accessibility Task Force has endorsed the <progress> element and
opposed the call to remove it.
While some have indicated that they believe these statements are based
on a "fallacious" or "booby trapped" assumption, the fact remains that
no specific unresolvable problem with this element has been identified
with this element to date. As such, we find that the claims that this
could lead to a "disaster" to be unsubstantiated.
--- Conclusion
None of the objections cite any specific clear and present danger posed
by this element. Each of the objections are weak.
*** Decision of the Working Group ***
Therefore, the HTML Working Group hereby adopts the Change Proposal to
"Keep New Elements and Attributes". Of the Change Proposals before us,
this one has drawn the weaker objections.
== Next Steps ==
Bug 8552 is to be CLOSED and marked as WGDecision.
Since the prevailing Change Proposal does not call for a spec change, no
further action is required.
== Appealing this Decision ==
If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.
== Revisiting this Issue ==
This issue can be reopened if new information come up. An example of
possible relevant new information include:
* An indication by at least one major implementer that they are either
unwilling or unable to implement this feature.
* Unresolvable bugs on specific function, accessibility, or backwards
compatibility of the progress element.