ISSUE-93 Change Proposal

Summary

    Summary: Eliminate the Details element, completely. Do not spin it
off into another specification, or wrap it in a specification of its
own.

Rationale

The HTML5 specification states:

    The Details represents a disclosure widget from which users can
obtain additional information or controls.

Two examples of the use of Details are given: one where additional
information is hidden; the other, where form elements are hidden
within a set of details elements. Whether the details body is shown or
not is based on the presence (or absence) of the boolean open
attribute. If open is present, the body is displayed; if not, the body
is not displayed. User Agents are supposed to respond in some way to a
user request to open the details element by setting this boolean
attribute, and to respond to a user request to close the details
element by removing this attribute.

The purpose for the element, as provided by the editor, Ian Hickson,
in the initial bug to remove it [1] is:

"The <details> element is needed to provide an accessible way of
reflecting a common application widget in HTML-based applications
without requiring authors to use extensive scripting, ARIA, and
platform-specific CSS to get the same effect."

Before I address the Details element, generally, and the editor's
stated purpose for the element, specifically, I want to discuss the
state of the art of this type of behavior as it exists today.

This type of behavior is well known and variously labeled a tabbed
page, an accordion widget, or a sliding/collapsible menu/form/page
section. The existing technology supporting this behavior is very well
understood:

    * All widgets feature a caption/label and associated section pair,
that may, or may not be enclosed within another container element.

    * A tabbed page widget typically features a layout where all of
the labels are grouped and clicking a label displays its associated
page. The first page is displayed, by default.

    * An accordion widget typically features a layout where all of the
labels displayed next to each other, and clicking a label opens the
label's section either directly beneath it, or to the side of the
label.

    * An accordion widget also typically only has one section open at a time.

    * A collapsible widget, whether used in a menu, sidebar, or form,
has a label and a section, and the section is display or collapsed
only when the label is clicked. The collapsible widget's page section
is not displayed, by default.

    * Control of the behavior for all three types of widgets is
implemented with a combination of JavaScript and CSS.

    * For all widgets, clicking the caption displays or expands the
body element if it is hidden or collapsed.

    * For the tabbed page, clicking the label for a new page also
hides the previously opened page.

    * For the accordion widget, clicking the label to display a new
section typically collapses the currently opened section.

    * For the collapsible widget, clicking the label when the widget
is in the open state, collapses or hides the body section.

    * There's usually a visual element representing the state for an
accordion or collapsible widget element—sometimes a triangle reflects
the state of the body element, other times, a plus or minus sign is
used

    * There's usually a visual element representing the state for a
tabbed page widget—the background color of the tabbed page's label
differs from the background color for the other labels. Other visual
indicators may also apply.

    * For an accordion or collapsible widget, clicking the caption or
label may display the body immediately, or it may trigger a timed
event, whereby the body element is displayed in smooth incremental
steps.

    * For an accordion or collapsible widget, when the widget is in a
collapsed or hidden state, the body section does not take up page
space. When expanded or displayed, content following the expando or
accordion section is pushed down (or over, if the element is a
vertical widget), making way for the content.

    * Best practices dictate that when JavaScript is turned off, all
tabbed pages for a tabbed widget are displayed by default, and the
labels either hidden by default, or aligned with the tabbed pages as
headers.

    * Best practices dictate that when JavaScript is turned off, all
accordion sections are displayed by default; the section labels may,
or may not, be hidden by default.

    * Best practices dictate that when JavaScript is turned off, a
collapsible widget's body section is displayed by default; the
collapsible widget's label may, or may not, be hidden by default.


As you can see, the tabbed page, accordion, and collapsible widgets
are more complex and richer than one would assume from reading
something such as the Details element. That's because in the current
state-of-the-art for these types of widget, where such behavior is
implemented with CSS and JavaScript, we have a higher degree of
control over every aspect of the widget.

Focusing specifically on the existing widget with behavior closest to
the Details, the collapsible section, following is a comparison of
control between how this behavior is implemented today, and how it
would work with the details element:

    * The visual indicator representing the state of the widget can be
modified using the JavaScript/CSS approach. At this time, the visual
indicator for the Details element is controlled by the User Agent.

    * Expanding the collapsed portion of the widget can be implemented
incrementally with the JavaScript/CSS approach. Tthe expansion of the
collapsed portion of Details has two states: fully open, fully closed.
There are no JavaScript controls to incrementally implement the state.

    * The expansion and collapse of a JavaScript/CSS collapsible
section is totally under the control of the web page developer and
whatever scripting libraries used. The details element is under the
control of both the browser and potentially the web developer, though
there is no way to cancel the details element's default behavior.

    * By default a well designed web page expands all hidden page
sections if JavaScript is turned off; users have come to expect this
encouraged behavior. By allowing an expandable section to exist
regardless of scripting, we're introducing a new and possibly
unwelcome web state. Moreover one, unlike Flash, Ads, or JavaScript,
or even CSS, the user can't control.

    * By default, a well designed web page expands all hidden page
sections if the page is printed (typically by providing a web page
where all of the elements are present, as defined in the web page, but
the JavaScript files have been removed). There is no way to turn off
Details, as well as turn off JavaScript. In fact, we would have to use
JavaScript to add the open attribute to the element in order to offset
the default behavior for the element.

    * The details element is not accessible— there is no support for
the element in any of the screen readers. There is WAI ARIA support
for the collapsible section. In fact, ARIA support is currently built
into many of the popular UI libraries, such as jQuery UI and the Yahoo
YUI ARIA menu plugin, the Google Web Toolkit, and so on.


By continuing the trend that has been established for the last decade
when it comes to widget (dynamic application) development, we have a
much greater control over every last aspect of how this widget
behaves. Moreover, this control does not come at the cost of
accessibility. If anything, with recent efforts related to WAI-ARIA,
we're seeing a greater integration of accessibility into dynamic
effects.

So, the details element is not superior to the current
state-of-the-art for this type of functionality. In addition,
implementing a well defined and well understood JavaScript/CSS/ARIA
behavior as declarative animation built into the HTML specification
introduces the potential for explosive growth in HTML.

Earlier, I listed several forms of web space widgets: tabbed pages, an
accordion, and a collapsible section. Only the last option is an
equivalent JS/CSS behavior comparable to the Details element. However,
it is feasible to list all three because if there's justification for
adding a declarative equivalent for one, there's equal justification
for adding a declarative equivalent for the other two...or for the
dozens of other commonly used, packaged JavaScript/CSS behaviors.

Once we've opened this declarative element door, it becomes
increasingly difficult to justify shutting it, again. This action
could lead to a never ending set of behaviors being integrated into
the existing and future versions of HTML—incorporating as elements
that which was gracefully handled by JavaScript and CSS. Taking this
action impacts not only browser makers, but also HTML editors, Content
Management Systems, validators, and other tools, which have to
increasingly expand and add new items, new objects, new behaviors.

More importantly, there is no graceful way of integrating this new
declarative elemental behavior in with existing JavaScript/CSS
application development. The existence of a Details element fractures
the clean separation between behavior, style, and structure that had
existed to this point, and has served us well, as witness the many and
sophisticated applications we use today.

We have to return, then, to the question of why are we adding this new
element? The HTLM5 editor has stated the reason is because of
accessibility, but as I demonstrated, we have applications, tools,
libraries, plug-ins, and widgets that already provide accessible
collapsible sections. Not only is the details element not
complementary to the existing implementations, we're sending a
confusing message about what direction web developers and designers
are supposed to follow. Do we encourage people to continue using
JavaScript, CSS, and ARIA? Or do we provide hit and miss declarative
animations—one element here, another element another time— that tell
people that yes, use JavaScript/CSS/ARIA for this, but not for that,
and maybe use them today, but not tomorrow? This very inconsistent
direction will not only not support accessibility, it could very well
generate a great deal of pushback against incorporating accessible
solutions.

Another rationale given in support of the details element is in the
comment section for the bug that led to this issue: web designers can
add collapsible web sections to web pages without having to get help
from developers. However, designers can do this now, with any number
of packaged libraries, using the same elements and attributes that
they would use for a section that isn't animated. More importantly,
the designers can do so now, and still have control over not only the
appearance of the collapsible sections, but even aspects of the
widget's behavior--choosing a library that allows the section to
expand and collapse slowly, as compared to one that does so all at
once.

A third rationale for the details element is that it doesn't require
JavaScript, and so we don't have to burden our pages with large
JavaScript libraries. Well, I'm not sure what folks are expecting but
I've not found libraries such as jQuery or Prototype to be
prohibitively large. In fact, their use is so integrated into today's
web world, that most CMS applications, such as WordPress or Drupal,
include these libraries by default. Yes, and provide widgets in order
to easily add collapsible menus, sidebar items, footer elements, and
so on. All one has to do is typically pick an option from a list.

Another aspect of the existing implementations, too, is that most
libraries and widget developers understand well the importance of
progressive enhancement. Based on this underlying concept, when script
is turned off, and the page is opened, the widget is set to be
expanded by default. So the individuals using these widgets never have
to touch JavaScript, or modify their page elements based on whether
scripting is enabled or not. The widgets just work, right out of the
box.

This same cannot be said with Details. Either the web page designer
has to define a secondary page for use for a non-scripted,
non-interactive environment, such as printing, or the designer is
going to have add their own JavaScript to close all Details left as
open, by default.

The details element, and others like it, such as progress, are the
wrong direction for the W3C to take, and for the HTML WG to pursue.
WAI-ARIA is to accessiblity, as behavior is to JavaScript, as CSS is
to style, as RDFa/Microformats/Microdata is to semantics, as HTML is
to page structure.  This separation of domains works, and by the
proliferation of Ajax-like functionality we see today, it works well.
I cannot see giving up the direction we've been following for the last
decade, for the promise of a few elements now, and hundreds of
single-purpose elements to come around in HTML 6, 7, 8, 9, and so on.

To summarize, the rationale for removing the details element includes:


    * The type of behavior encompassed with details is well
understood, and simple to implement with existing technologies.

    * Existing implementations of this type of behavior allow for an
amazing number of variations in how the behavior is applied, giving
web developers far greater control over the behavior.

    * There is WAI-ARIA support for this type of functionality, but
there is no accessibility support for details

    * There are dozens possibly hundreds of widgets, libraries,
plug-ins, and so on support this behavior, and can be as simple to
implement as adding a class name to an element.

    * Many Content Management Systems, such as Wordpress and Drupal
provide built-in support for these types of widgets

    * Introducing declarative animation into HTML also introduces
problems with printed pages and other environments where scripting is
disabled and the expectation is that such elements would be open, by
default.

    * Introducing declarative animations as replacements for
JavaScript/CSS/ARIA behaviors now, opens the door for a proliferation
of such elements in the future, not only adding to the processing
burden on browsers, but also adding to the complexity of HTML editors,
CMS, WYSIWYG tools, and others.


Details

Based on the March 4th draft of the HTML5 specification, remove
Section 4.11.1, which defines the details element, and all other
references to it within the HTML 5 specification. This includes
removing Section 10.4.3, containing a description of the details
rendering.

Impact

Positive Effects

Removing the details element allows us to continue to progress with
our use of JavaScript, CSS, and ARIA to create interesting, diverse,
and accessible dynamic behaviors. It also prevents a possible
explosion of such declarative animations in the existing and future
versions of HTML, which will adversely impact on browsers, HTML
editors, validators, and other tools.

We're free to continue using the tools we have now, rather than having
to stop and change direction. And since this type of widget/behavior
is so well understood and supported (through the concept known as
progressive enhancement), we can turn off JavaScript if we don't wish
the web pages we visit to use JavaScript, but still be able to have
finite control over the behavior, as well as appearance of the widget.
Best of all, because ARIA is being incorporated into these existing
tools, we're adding accessibility to our web applications without
having to change one line of code, or one line of markup.

We're removing the potential conflict that something like the details
element introduces. Today users have the ability to turn off Flash and
JavaScript, but we don't have any way to control declarative
animations. Taking control away from the users is not a direction I
think we want to take in the HTML WG.

Negative Effects

This change will take some of the HTML5 editor's time to implement. In
addition, if we wish to incorporate collapsible sections into our web
pages, we will have to use JavaScript.

References


http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13


http://test.cita.illinois.edu/aria/tabpanel/tabpanel2.php


http://drupal.org/node/99973


http://docs.jquery.com/Plugins/Validation#Example

Received on Wednesday, 31 March 2010 13:10:54 UTC