Working Group Decision on ISSUE-96 progress

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/96
http://lists.w3.org/Archives/Public/public-html/2010Nov/0234.html
http://lists.w3.org/Archives/Public/public-html/2011Jan/0356.html
http://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.

Received on Saturday, 19 March 2011 14:15:15 UTC