Author: Shelley Powers

Summary

Summary: Remove the aside element.

Rationale

Originally, my request for the aside element was to tighten its focus, and clean up the allowable content and usage. As I discovered with the figure element, though, covered in the Issue 90 change proposal, the more I looked at the element the harder time I had finding a good, solid reason for it to exist. Evidently, neither can the HTML5 editor, if one goes by the rationale he provided for rejecting my request to clarify the semantics, and structure, of the element:

Rationale: Concurred without counter-arguments above. As Shelley says, the draft was updated based on feedback from Web developers. Given that Web developers are the people who will be using this technology, that seems wise, and not at all something to be ashamed of.

If the element is so unimportant that the editor can’t provide a rationale other than a vague “web developers” want it, in the bug associated with it, then it is too unimportant to keep in the specification. However, the editor’s hubris aside, there is nothing “semantic” about the aside element, nor is there anything really useful about having the element. Consider its definition:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

There’s a reason in the print world why sidebars are separate elements: they trigger different typesetting. There’s also a reason why sidebars are many times published slightly out of context of their use: they are large, and typographically, not always easy to fit into the text where they would be most appropriately placed. Tangential placement has meaning in the print world, but less so on the web, where everything can be tangentially related to everything else via a link or happenstance physical proximity because of web page design.

It’s a confusing element, too. Because of the use of “sidebar” in the definition, people are assuming that the aside element is really a sidebar element, as sidebar is known in the web context. They’re two separate things, though, regardless of name used. A sidebar in the web world should more properly be another section element, as the main column is a section, or perhaps a div element. Frankly, I’m not sold on the usefulness of section, either, but that’s outside of the scope of this change proposal.

The HTML5 editor did not intend aside to be a sidebar element[2], as sidebar is known on the web. What was the original intent, though, is lost in the confusion surrounding the element[3]. For instance, folks have had a hard time differentiating it from figure[4], because both sound almost identical, except that figure had a caption. Semantic markup should not be causing such confusion. That it does implies that people don’t understand the purpose for this element.

The key to understanding whether aside is useful or not is to ask ourselves what it provides from a web perspective that can’t be met by other elements (in combination with semantic markup, such as RDFa, Microformats, or Microdata, ARIA, or CSS). If the material in the aside is supposedly material that can be removed from the document, document in this case being some form of article, from a web perspective, this is material that is not contained as a child of the article element. If it is to be tangentially related, the article and the sidebar could share a parent element, or be tangentially related via a link.

Again, repeating what I stated earlier, we’re not faced with the same restrictions as the print world, where even tangentially related material has to be included within the actual document, itself. We can put material anywhere on the web, and tangentially relate it to the article with a link. If the aside is equivalent to a print world sidebar, then it could be just as easily moved to another section in the same web page, or even another web page and linked. We don’t need a special purpose element in the web world, because we’re not facing the same constraints as the print world.

Now, evidently the aside element can now be used as a sidebar, which further weakens its usefulness. How is the typical sidebar content we see on the web even tangentially related to the existing document? Other than a link to the document may or may not exist in the sidebar? Or do we even know what “document” is, in this case? Is the web page the document? Or only a specific article within a section within the web page? Again, what has meaning in the print world does not necessarily carry over easily into the web.

A semantically meaningful element should be one that, when a person first sees its description, he or she goes, “I can use this. I have needed this.” I’ve not seen this in response to the aside element, except when people are defending it’s existence in the HTML5 specification. The statements such as “I need this, I can use this”, should come first, before the element is defined, not after.

I’m not sure who first asked for the element, I haven’t been able to trace its roots. Regardless, I’ve not seen many in the web design and development world jump up and down with joy for its existence, primarily because most people are still scratching their head over it, wondering what it is, and why they should use it. The aside element has been a point of confusion in the past, and is still a point of confusion now, and will not somehow become magically less confusing in the future[5][6][7][8].

The HTML5 so-called Superfriends wrote a manifesto of support for HTML5, which also included the following[7]:

We are excited about the the ability in HTML5 to scope headings via the section element. This proposes a significant improvement in fluidity of content reuse and eases the burden of creating mashups….We would like to encourage spec authors to be conservative in including new tags, and only do so when they[sic] addition of the tag allows for significant gains in functionality. (emphasis mine)

There is a cost associated with every new element, attribute, and specification change. The cost is to browser developers, but in the case of an element like aside, more so to HTML editors, Content Management Systems, and other tools that now have to incorporate support for yet another new element. The cost is also to web designers and developers, trying to figure out what to use, and when.

If we’re truly concerned about helping web developers, we’re not doing so by introducing confusing elements. If it’s not semantically meaningful, or structurally useful, it should be removed.

Details

Based on the March 4th publication of the HTML5 specification, remove Section 4.4.5, on the aside element, and any other reference in the specification to the aside element.

A better approach would be to use existing elements, such as a div element, style it with CSS, and attach semantics using ARIA, RDFa, Microformats, or Microdata. After all, we now have four different ways we can apply semantics to a web page—we don’t need to create single purposed elements, too.

Impact

Positive

Removing the aside element removes a element that has generated confusion since its first release—a confusion that doesn’t seem to lessen over time. The element provides little in the way of semantics, because it’s more or less based on a construct from the print world, and doesn’t really have much application in a web environment. Structurally, it provides nothing useful.

Removing the element reduces the confusion, but is also a cost saver in the future for HTML tool builders. Though browsers can more or less treat aside like a div element, HTML editors and other tools cannot. If there was a genuine purpose for the existence of the element, the cost would be justified. But the element’s definition is now so general that we might as well consider it a synonym for the div element.

Negative

Removing the element will require Editor time.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8447

[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017596…

[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/023435….

[4] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020267.html

[5] http://html5doctor.com/understanding-aside/

[6] http://html5doctor.com/aside-revisited/

[7] http://www.zeldman.com/superfriends/guide/

[8] http://www.webmonkey.com/2010/02/building_web_pages_with_html_5/#.3Casid…

Summary

Summary: Replace too-simple and somewhat odd example table and verbose text unrelated to the table element, with one example table, derived from real world data that best demonstrates the table element. Refocus the text specifically on the table element.

Rationale

In the bug[1] related to this issue, the HTML5 Editor’s rationale for not make this change was:

Rationale: Given how bad the current situation is regarding authors providing explanatory text for tables, I think we should given them as much information as possible, in as many places as possible. We do AT users a disservice if we pretend that their needs aren’t important enough to include advice on how to best serve them in the spec.

The current table element section provides one very small and inadequate table example, with a great deal of prose basically telling people what to put in text surrounding the table. None of this prose is related to the purpose and interoperable use of the table or its child elements, and seemingly added to the section only as a way of justifying removing the summary attribute. I hate to use cliches, but this seems like a true case of the tail wagging the dog.

Throwing lots of irrelevant text at authors does not make the table element any clearer, or ensure they use the element in the proper way. What’s needed is a good, succinct example, with a clear explanation of the element, and the table’s only unique attribute, summary.

What people incorporate into the text surrounding an HTML table is not the business of the W3C HTML Working Group. Such over-specification only adds to the noise, and if you throw enough noise at people, all they’ll do is tune out the important bits.

The space would be better used by providing a table listing that uses all of the table child elements, demonstrating how the elements work together, and then providing a screenshot of the table. By creating a listing, people can see how the table is put together; the figure demonstrates the visual rendering of the table.

Details

Replace the existing table element description section with the following (replace the URL for the img element in the figure with one local to the W3C, image can be copied, link table model):

The table element represents data with more than one dimension, organized into non-empty columns and rows. It is the primary component of the table model.

Tables are used for data display, only, and should not be used for layout purposes. In particular, users of accessibility tools like screen readers are likely to find it difficult to navigate pages with tables used for layout.

The only unique attribute for the table element is the summary attribute. This attribute is optional, and should only be used with complex tables, in order to provide a visual description of the structure of the table—making the table easier to navigate when rendered non-visually. The summary may also include a brief description of the purpose of the table, if such purpose is visually apparent when viewing the entire table, but may not be apparent traversing the table, cell by cell. An example of a complex table is shown in Listing Table-1. Figure Table-1 is a visual rendering of the table.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Example Table</title>
<style>
table
{
  border: 1px solid #ccc;
  border-collapse: collapse;
  margin: 0 20px;
}

td, th
{
  border: 1px solid #ccc;
  padding: 10px;
}

.female
{
  background-color: #ffc;
}

tfoot
{
  font-size: smaller;
}
</style>
</head>
<body>
<table summary="First row is column headers separated into year and degree programs 
                (bachelor, master, graduate). Each degree program is further split into 
                biology and technology fields on second line. Each topic field is separated into 
                male and female graduates on third row. Years are listed in first column.">

   <caption>
      <p>Degrees in the biological and biomedical sciences compared with degrees 
         in technology conferred by degree-granting institutions, by level of 
         degree and sex of student: Selected years, 2002-2007.
      </p>

   </caption>

   <colgroup span="1"></colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />

      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />

   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>

   <thead>
      <tr>
         <th rowspan="3">Year</th><th colspan="4">Bachelor's Degrees</th>
         <th colspan="4">Master's Degrees</th>
         <th colspan="4">Doctor's Degrees</th>
      </tr>

      <tr>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th></tr> 
      <tr>
         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>

         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>
      </tr>
   </thead>
   <tbody>
      <tr>
       <td>2002</td><td>22,918</td><td>37,186</td><td>41,950</td><td>15,483</td>

                    <td>2,981</td><td>4,009</td><td>13,267</td><td>6,242</td>
                    <td>2,804</td><td>2,289</td><td>648</td><td>168</td> 
      </tr>
      <tr>
       <td>2003</td><td>23,248</td><td>38,261</td><td>44,585</td><td>14,903</td>

                     <td>3,227</td><td>4,430</td><td>13,868</td><td>6,275</td>
                     <td>2,804</td><td>2,438</td><td>709</td><td>200</td> 
      </tr>
      <tr>
       <td>2004</td><td>24,617</td><td>39,994</td><td>42,125</td><td>11,986</td>

                    <td>3,318</td><td>4,881</td><td>13,136</td><td>5,280</td>
                    <td>2,845</td><td>2,733</td><td>905</td><td>214</td>
      </tr>
      <tr>
       <td>2005</td><td>26,651</td><td>42,527</td><td>37,705</td><td>9,775</td>

                    <td>3,654</td><td>5,027</td><td>12,470</td><td>4,585</td>
                    <td>2,933</td><td>2,842</td><td>1,109</td><td>307</td>
      </tr>
      <tr>
       <td>2006</td><td>29,951</td><td>45,200</td><td>34,342</td><td>7,828</td>

                    <td>3,568</td><td>5,179</td><td>11,985</td><td>4,247</td>
                    <td>3,221</td><td>3,133</td><td>1,267</td><td>328</td>
      </tr>
   </tbody>
  
   <tfoot>

      <tr>
         <td colspan="13">Data from Institution of Education Sciences National Center
                for Education Statistics, derived from two tables: 
                <a href="http://nces.ed.gov/programs/digest/d08/tables/dt08_298.asp">
                Table  298. Degrees in the biological and biomedical sciences conferred by degree-granting 
                institutions, by level of degree and sex of students; selected years, 1951-52 through 2006-07
                </a> and <a href="http://nces.ed.gov/programs/digest/d08/tables/dt08_302.asp">
                Table 302. Degrees in compueter and information sciences conferred by degree-granting 
                 institutions, by level of degree and sex of student: 1970–71 through 
                 2006–07</a></td>
      </tr>
   </tfoot>
</table>
</body>
</html>

Summary

Remove the srcdoc attribute.

Rationale

The original bug report for removing srcdoc provided the following change request[1]:

This recent entry does not have universal acceptance, and the group was still discussing it when the editor added it to the specification.

The supposed use case for this attribute is weblog comments, but concerns about HTML security have been resolved with weblog and other application comments years ago. In addition, support for this attribute could give the impression that online sites don’t need any other security, which is false. Script injection is only one aspect of security related to weblog comments, and considered a fairly trivial one at that.

This needs to be removed from the specification.

The rationale given by the HTML5 Editor for keeping this attribute:

Rationale: I’m happy to remove this attribute from the W3C HTML5 specification if that’s what the working group wants. The last time I removed a feature based on a bug report such as this, I started a minor war, however, so I suggest that you raise this via the change proposal process if you really feel this way.

According to the HTML5 editor, there is no rationale for keeping this attribute. That made this change proposal more difficult to write, because I had to base my arguments on guesses and scraped email messages.

There was a great deal of contention about this attribute before it was added. It spawned another issue (Issue 103) because of concerns about escaping the markup in the attribute, especially for XHTML. That this caused some difficulty for members of this group, who are defining the next version of HTML/XHTML, should give us pause, because knowing what must be escaped is going to be that much more difficult to the average web developer[2][3].

When asked the purpose for srcdoc, the HTML5 Editor replied that the use case for the attribute is weblog comments[4]. Because the srcdoc attribute works within a sandboxed context, the use of the attribute would prevent script injection in comments. Since this change was targeted to a specific use related to weblog software, I asked Matt Mullenweg[5], the creator of WordPress, one of the more popular weblogging tools in use today, about the usefulness of this attribute. He responded with[6]:

We haven’t had any HTML-level problems in comments in a while.

We use and maintain a library called KSES that we use for all sanitation, and it has served us well.

I brought Matt into the discussion for two reasons. The first is that I wanted to bring in an “implementor”, and demonstrate that an implementor, in the case of weblog comments, is the the group or individual responsible for the weblogging software. Too often this group is focused purely on browser developers as implementors, forgetting that browsers are not the only application group impacted by HTML5 changes.

The second reason was to demonstrate that no one from the weblogging community has asked for this, and it is very unlikely that many, if not most, of the weblogging community will use this uncomfortable, awkward attribute. The weblogging community has long had to deal with security problems, and has devised sophisticated tools and techniques to not only protect against script injection, but also SQL injection, the greater hazard for weblog comments, and even the accidental wayward insertion of a non-printing character in XHTML.

In point of fact, relying on something such as srcdoc can make a site less secure rather than more, because it only touches on one vulnerability, when we’re faced daily with a host of new and ever more sophisticated threats[7].

So the use case is heavily flawed. What are the other issues associated with srcdoc? I’ve already mentioned the concerns about escaped characters, and how this will differ between HTML and XHTML, which in itself will discourage its use with most applications like Content Management Systems. Are there other issues?

Another issue is when something like srcdoc can be used, and if the restrictions of the use are such as to defeat its use. This attribute can’t be used effectively for potentially years in the future, because web browsers don’t print out what’s contained in the attributes—not unless specifically directed to do so[8]. Until then, the fallback is used, which is the iframe’s src attribute. In the meantime, our existing applications that do provide security become more sophisticated, more capable, more tightly integrated, until by the time we could use srcdoc effectively, few of us will even remember what it is, and fewer still, would be interested.

An alternative to srcdoc was suggested in the discussion surrounding this attribute. Instead of embedding markup in the attribute—something that has been actively discouraged for some time— we can use a data URI with the src attribute, getting the same functionality that can be more quickly usable and won’t require us to embed markup in an attribute. However, the data URI has its own challenges, specifically the fact that the data would be printed out without the security controls in legacy browsers [9]. Again, though, using a data URI in an iframe src attribute would most likely never be used for weblog comments. I find it unlikely that any approach related to the iframe and sandboxing will ever be used with weblog comments, so it might be best if another use case is used to attempt to defend this attribute.

One use case that does come to mind are the plug-ins we drop into our web pages. The source of the plug-in comes from an external site, which could be cause for alarm. However, plug-in security is not related to the srcdoc attribute, so I have a hard time determining what use case would apply. Perhaps there are none, in which case, there’s even more of a reason to remove this potentially harmful, most definitely problematic attribute.

Details

Remove all references to the srcdoc attribute from the HTML5 specification. If such a removal results in a gap in coverage, consider following one of two paths: remove whatever other material is necessary to eliminate the gap or work with the W3C HTML WG to come up with an alternative approach, if one can be found.

I would also strongly suggest finding another use case, if you want to pursue this type of functionality.

Impact

Positive

Removes a confusing, potentially harmful, and not really usable attribute, either forcing us to re-address the issue, or to consider dropping this particular subset of web page security from the HTML5 specification. Perhaps there are some aspects of the web that cannot be managed by browsers.

Negative

Requires some of the Editor’s time to make the change. Could potentially leave a gap in coverage, if this subset of security is still of interest. Would require more work in the HTML WG. However, counter proposals to this proposal might be able to provide effective alternatives. Or not, if none really exists.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8818

[2] http://www.w3.org/html/wg/tracker/issues/103

[3] http://lists.w3.org/Archives/Public/public-html/2010Mar/0431.html

[4] http://lists.w3.org/Archives/Public/public-html/2010Jan/1193.html

[5] http://lists.w3.org/Archives/Public/public-html/2010Jan/1223.html

[6] http://lists.w3.org/Archives/Public/public-html/2010Jan/1337.html

[7] http://lists.w3.org/Archives/Public/public-html/2010Jan/1318.html

[8] http://lists.w3.org/Archives/Public/public-html/2010Jan/1325.html

[9] http://lists.w3.org/Archives/Public/public-html/2010Jan/1346.html

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¹ 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 other 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. It 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 so on.

Details

Based on the March 4th draft of the HTML5 specification, remove Section 4.11.1, which defines the detals 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, tools, and so on.

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, we can do so without having to use JavaScript if we don’t wish 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

Summary

Summary: Remove the progress element.

Rationale

In the bug associated with this issue[1], the HTML5 editor, Ian Hickson wrote as rationale for turning down the change request:

Rationale: <progress> fixes a serious accessibility problem with dynamic apps, and accessibility is important.

I have to make a guess about what serious accessibility problem progress solves, since the editor did not specifically state it. I’m assuming the problem is the fact that the information given visually by the progress bar is not vocalized by screen readers.

According to the HTML5 specification, there are two types of progress element: indeterminate, like a throbber, and determinate, like a progress bar. The indeterminate progress element is like the many we’ve seen in web pages—it’s a simple animated graphic that basically implies, “working…”. The determinate progress bar is like those we’ve seen where a bar is filled in from let to right, the amount filled in representing the completion status of a task.

Something like a progress element is useful, which is why we’ve had graphical and JavaScript/CSS based progress indicators for over ten years now. I created my first progress bar using a small GIF element and a timer close to 15 years ago for my first book on JavaScript.

Addressing the individual types of progress element, beginning with the indeterminate, there are indeterminate progress graphics that spin and pulse, and twitch about, all with an alt text along the lines of “The task is in process”, or the like. There is absolutely nothing that the indeterminate state of the progress element provides that we don’t already have, and yes, which is accessible, too. More accessible, as there is nothing in the specification about the element that specifically addresses accessibility. If we want more, though, we can also annotate the progress indicator with WAI-ARIA values, as discussed next.

I’m assuming that the greater concern about progress indicators is related to the second of the progress element types, the determinate progress bar, which provides indication of how far along the task is, and how far it has to go. As Mozilla demonstrated[2] some time ago, though, we’ve had accessible progress bars for some time now, thanks to the WAI-ARIA effort. In particular, the use of role=”progressbar”[3], with associated ARIA states, aria-valuenow[4], aria-valuemin[5], aria-valuemax[6], and the optional aria-valuetext[7], provide all the information that’s necessary to ensure that the progress of the task can be tracked by those using a screen reader.

From an accessibility perspective, using the progress element isn’t simpler than the ARIA values. The min and max values, whether ARIA or progress element, are statically assigned in the associated element, and the current value is updated based on the progress of the element. What does differ is that the progress element does have a visual indicator that is automatically updated. Unfortunately, though, it’s a visual indicator we have no control over. What we see, is what we get. It will differ based on operating system and user agent. We only have minimal control over how the element can be styled.

Compare that to the options we have available in various libraries today. There are sites that provide the ability to create our own throbber (indeterminate progress)[8], as well as dozens if not hundreds of existing images freely available on the web that we can use. Annotate with a little ARIA, and we’re set.

As for indeterminate, there are too many available libraries for this functionality to list, but I wanted to specifically point out the jQuery UI progress bars[9], as jQuery UI does have ARIA accessibility built into the library. Dojo’s widget library Dijit has promised complete ARIA integration, and already made strides in that direction, especially with the progress bar[10]. So has the YUI 2 ProgressBar[11], as well as other popular libraries.

A decade ago, when HTML4 was newly released, something like progress would have been welcome. At that time, support for JavaScript and CSS was limited, and accessibility support was non-existent. That was years ago. Now, there are several progress bar options available that are well designed, fast, efficient, accessible, and which we can use as easily as we use CSS now. They are truly plug-and-play simple. Not only do these libraries and plug-ins and packaged widgets provide the progress element’s functionality, they do a superior job, both from an accessibility perspective, and the fact that they work now. They also provide user options for styling and behavior far beyond what we could ever have with the progress element, and how we style the progress bar packaged widgets transcends both browser and operating system, to provide a nicely consistent appearance and behavior.

Details

Based on the March 4th, 2010 draft, remove Section 4.10.16 and Section 10.4.13 and any references to either and to the progress element.

Impact

Positive Effects

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.

Negative Effects

Will require some of the Editor’s time to make the change. Since the element has not been implemented in any browser or other user agent (that I’m aware of), there should be no cost associated with having to remove support for the element other than editing the specification.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552

[2] http://www.mozilla.org/access/dhtml/progressbar

[3] http://www.w3.org/TR/wai-aria/roles#progressbar

[4] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuenow

[5] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemin

[6] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemax

[7] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuetext

[8] http://www.ajaxload.info/

[9] http://docs.jquery.com/UI/Progressbar

[10] http://docs.dojocampus.org/dijit/ProgressBar

[11] http://developer.yahoo.com/yui/progressbar/