Burningbird

Remove the Hidden attribute

Post author By Shelley Powers
Post date April 26, 2010

My change proposal for Issue 95 is about removing the hidden attribute[1]:

The HTML5 specification states the following about this attribute[2]:

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified…

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

The hidden attribute section provides one example: a game screen is hidden until a person has logged in.

Rationales for Keeping the Attribute

The HTML5 editor, Ian Hickson, wrote the following rationale as reason for rejecting this change in the associated bug[3]

Rationale: hidden=”” is a key part of HTML5’s accessibility story and represents one of the main accessibility improvements over HTML4 for dynamic applications.

A counter-proposal has been provided to keep the attribute. The rational given is[4]:

Authors of web documents and applications often need to temporarily hide certain content from readers and users.

Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It’s clear that hidden=”” Solves Real Problems.

Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden=””. hidden=”” is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design.

By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies.

Bolt-on emulations of hidden=”” can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools. hidden=”” thus promotes Accessibility more than bolt-on alternatives.

In addition, the Accessibility TF discussed the change proposal[5], and among the benefits discussed were the following:

Not so strong on keeping the hidden attribute.
Hidden does what the ARIA equivalent does, and seems useful.
Could live without it given we will get it in aria.
It’s like display:none but without the nasty side effects.
It is slightly different from aria-hidden…
HTML5 hidden applies to ALL elements
Not sure this has an accessibility impact…
There is some impact (but not a lot).

The Accessibility Task Force also provided a general statement regarding this element and others:

RATIONALE: The F2F believes these elements are actually useful for accessibility. We note that features similar to the elements in question are today created using elements with different semantics actuated by style and script, whereas we prefer native elements.

Response

I took a best guess effort at summarizing the rationales for keeping the hidden attribute.

It provides accessibility support where none existed in HTML4
Implementing the hidden functionality with JavaScript and CSS is difficult and error-prone
It’s the simplest thing that can work
It works with all media
It is semantically meaningful

I say “best guess” at summarizing, because the discussion points from the Accessibility TF seem to indicate that some members of the discussion don’t think the hidden attribute is particularly useful.

I do agree with the counter proposals that the hidden attribute is easy to use. From the example in the specification—set the value to true, to hide the element’ contents, false, to display the contents—you can’t get a simpler attribute. I also agree that HTML4 did not have an equivalent functionality built into the specification. However, I do not agree with the other statements given.

The Existing Behavior with JavaScript and CSS, Media, and Simplicity

The HTML5 specifications defines the rendering for the hidden attribute to be equivalent to setting the element’s display property to “none”[6]. You’d get the same effect with the following code:

document.getElementById("elem").style.display="none";

Or the following code:

document.getElementById("elem").setAttribute("style","display:none");

As you would setting the hidden attribute:

document.getElementById("elem").hidden=true;

You could even absolutely, positively, completely ensure the accessibility of the effect, using the following:

[aria-hidden="true"]
{
   display: none;
}
...
document.getElementById("elem").setAttribute("aria-hidden","true");

If any user agents do render content when the element’s display property is set to “none”, it’s the fault of the user agent, not the CSS or aria-hidden attribute. If user agents have problems with display being set to “none”, they will continue to have problems with the hidden attribute because the two are equivalent.

As for simplicity, both approaches are again, exactly equivalent.

The Semantics of Irrelevance

The hidden attribute was once named the irrelevant attribute, supposedly because the attribute is used to mark the contents of whatever element it is attached as “irrelevant”. The attribute was renamed because, a) the irrelevant term was confusing, and b) techs misspell words like “irrelevant”.

Is the content truly irrelevant, though? Consider the definition for the attribute:

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

An irrelevant element is not one that is active, receiving events, participating in the web page, or form submission. The only truly irrelevant page component is one that doesn’t exist. If people want a truly irrelevant page section, they should use the DOM to create and remove the element, as needed. There is nothing about the behavior associated with removing an element from user agent rendering that is made more meaningful using a single-purposed HTML attribute, rather than using a simple combination of CSS property and ARIA attribute. Both have to do with the presentation of the element.

Presentation with the hidden attribute isn’t an incidental purpose, it is the primary purpose of the attribute. Rather than separate presentation and structure, it firmly welds the two.

Accessibility

The hidden attribute is no more accessible than setting the element’s CSS display property to “none”, because the two are equivalent.

However, the hidden attribute can be detrimental to accessibility because there’s nothing in the HTML5 specification that describes the precedence of settings. The ARIA documentation states that ARIA settings, such as aria-hidden, take precedence over settings such as display=”none”. Does the aria-hidden attribute have precedence, then, over the hidden attribute? How about when hidden is set to true, but a CSS stylesheet sets the display property of the element to “block”?

Introducing hidden introduces a redundancy, yet the documentation for hidden does not take such redundancy into account when defining the attribute.

Costs

The costs for an attribute such as hidden, are not as high as a more complex object, such as the details element. However, there are costs. Lint tools and validators now have to ensure conforming use of the attribute, HTML editing tools and WYSIWYG applications have to incorporate the new functionality, libraries have to be modified, books updated, design themes modified, and so on.

Web developers and designers have to spend time trying to figure out when to use CSS, and when to use the hidden attribute. I can imagine the many discussions about ‘irrelevant” content, and what does “irrelevant” mean in one context or another. It is an esoteric concept, and as such adds unnecessary complexity.

If the attribute provided something useful, it might be worth the costs. However, the hidden attribute provides absolutely nothing that we don’t already have.

On being an HTML5 deletionist

Post author By Shelley Powers
Post date April 25, 2010

When last I posted, I was confident I would be finished with my change proposals for the HTML5 by now. Little did I suspect at how strong a reaction my proposals would have, or how emotional the discussions would become. Some of the responses were humorous, such as when I was called a “deletionist”, of all things. Most of the responses, though, were not pleasant.

Ian Hickson, the HTML5 editor, framed his replies rejecting my changes in terms of accessibility and that’s how I responded. As was noted by the wise woman in the group, Laura Carlson, the use of accessibility in this regard was likely a red herring. However, when you write a change proposal, all you can do is respond to the presented arguments. Now, there have been additional arguments, and I’m adjusting my response accordingly.

I was disappointed in how my change proposals were treated. I didn’t expect the HTML5 WG co-chairs to encourage people to respond with one counter-proposal for several of my change proposals. Though each of the impacted proposals was about removing an element from the HTML5 spec, each element is unique. Or at least, I though they were unique. The response leads me to wonder: if people respond with a blanket statement about all elements, how unique are they, really? And how useful?

The Accessibility TF responded in support of keeping the elements, but again, grouped all the elements together in the group response. This following from the groups having marked the original bugs as outside of the group’s interest. That this response was inconsistent didn’t seem to matter—built-in elements are better for accessibility, regardless of the elements.

Back in the HTML WG, I have been met with a block of voices all clamoring, “We want the elements”. My first reaction when met with the fairly strong resistance was to bag my change proposals, and just let the overly large HTML5 specification be that much larger. Such a response, though, would not be honest—I genuinely believe that not only are these elements not useful, their costs exceed whatever perceived benefit they may bring.

Now, a few months later, I’m making final edits to my change proposals in response to the blanket counter-proposal and the one paragraph response from the Accessibility TF. You can read my work for the first change proposal I’m editing, related to deleting the details and summary elements. I’ll post my work in progress for the other change proposals as I finish.

Yours truly,

the Deletionist

HTML5 Specs

Removing the Detail and Summary elements

Post author By Shelley Powers
Post date April 24, 2010

One of my HTML5 change proposals is to remove the details element[12].

The HTML5 specification states[1]:

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 used with additional information, and one used with form 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.

Rationales for Keeping the Element

The rationale for keeping the element provided by the editor, Ian Hickson, in the initial bug to remove it is[2]:

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.

A counter-proposal has been provided to keep the element. The rationale in the counter proposal is[3]:

The notion of “optional” content that can be skipped over when reading the main content is a useful semantic to express.

This semantic is used in many webpages. For example, forms sometimes contain optional sections that are not necessary to successfully submit the form, but allow you to give extra information. Message boards often have a “spoiler” feature for hiding long sections of content that aren’t necessarily useful (such as a long digression proving some point used in an argument) or that readers may want hidden until they choose to view it (such as conversation about a movie or book that concerns important plot details).

The <details> element expresses this semantic, indicating that its contents may be optional or are otherwise suppressed, but may be called up and viewed or interacted with easily. The <summary> element provides a short description of the content within its <details> parent.

In addition, the Accessibility TF discussed the change proposal[4], and among the benefits discussed were the following:

Specific behavior associated.
Makes a control for a behavior that is frequently done in script. what details does is frequently done (badly and inaccessibly) in script.
Specifically useful for accessibility.
Authors often roll their own without getting the accessibility right, and it is expensive.
Details isn’t trivial to do in Javascript.
There are things without elements, like accordions – I’d like to see elements for those too, rather than removing this one…from an interaction design perspective she might have a point that these are similar.

The Accessibility Task Force also provided a general statement regarding this element and others:

RATIONALE: The F2F believes these elements are actually useful for accessibility. We note that features similar to the elements in question are today created using elements with different semantics actuated by style and script, whereas we prefer native elements.

Response

Summarizing the rationales for keeping details:

This type of behavior occurs frequently
This type of behavior is semantic
Implementing this type of behavior with JavaScript and CSS is difficult, error-prone, and inaccessible
Generally, built-in elements are more accessible than their JavaScript/CSS equivalents

Starting from the top, I agree that this type of behavior occurs frequently. So frequently, in fact, that there are variations on the behaviors, and the concept of a collapsible, hidden page section has been incorporated into higher level accordion, popup menu, and tabbed page applications. This type of behavior has also been in use for many years, and is implemented in most User Interface libraries, such as Yahoo! UI (YUI), jQuery, Dojo, Mootools, and others.

Therefore, I agree with those providing counter-proposals that this type of behavior is common. However, I do not agree with the other rationales/assertions given.

Behavior is not semantics

I disagree with the assertion that this type of packaged behavior is “semantic”. There is nothing semantic about managing web space more efficiently by hiding a page section and only displaying the section based on some event. It is a convenience, a way of simplifying the presentation of the content.

Consider a page that has collapsed sections compared to a version of the same page, identical in every other way, except that it doesn’t use collapsible sections. The meaning of the page, or its contents, doesn’t differ between the versions. In fact, the concept of progressive enhancement is based on the principle of providing the same content regardless of whether JavaScript is enabled or not. The details element is nothing more than a declarative element mimicking a well know JavaScript/CSS enabled behavior—if the use of a JavaScript-enabled collapsible section does not change the meaning of the page, or its content, the existence of a built-in alternative does not either.

I created four pages, each with collapsible sections. One implements the behavior with a div elements, similar to what we might find given in earlier examples (a “for more details section”)[5]; one implements the collapsible section behavior with form elements[6]; another with an unordered list, like we might use with a menu[7]; the last with table rows[8].

Access the pages using a JavaScript-enabled browser, then turn the JavaScript off and access the pages again. The contents of the page do not change based on the presence of JavaScript or not, nor does the overall page meaning change. The use of the collapsed sections is a way of managing web page space: nothing more, nothing less.

The collapsible section is a purely presentational construct, implemented using JavaScript and CSS.

Difficulty of Implementing Collapsed Sections

Another rationale given for keeping the details element is that creating collapsible sections using JavaScript and CSS is difficult. The examples I just listed are using the exact same JavaScript, except for one minor line change in the table example for IE8, to work around a browser bug. The exact same code—and the code is more verbose than it needs to be, to make it easier to read. The examples are also keyboard accessible, as well as annotated with ARIA.

The amount of code is insignificant, and that’s with me coding the behavior from scratch. This type of collapsible section is implemented in most UI libraries, and typically only requires either a single function call, or that we annotate a couple of page elements with a specialized class value. We’d probably annotate the elements anyway, in order to create the element’s unique style.

Not only is the amount of code needed small, it’s also important to note that the label/content sections of the different examples also make use of elements relevant to the uses. The form example uses form-specific elements (fieldset and legend); the table example, a table element (table rows). Even the use of an unordered list for the menu items is extremely common, as is the use of the div elements for the “more details” implementation.

Being able to apply the same behavior to different page elements should be encouraged. Trying to integrate a details element into a table element or form element, in order to implement the same behavior I demonstrated in my examples, is not only awkward, there’s a very good possibility the use of the element would fail conformance tests, if it even worked. When you introduce elements to take the place of JavaScript behaviors, you introduce changes to structure, as well as behaviors—we have far less flexibility when applying changes to structure than to modifying the behavior of existing elements.

The User experience and Accessibility

The last rationale associated with keeping the details element is the supposedly superior accessibility of built-in elements, such as details, as compared to JavaScript-enabled behaviors. Let’s look at the accessibility associated with the details element.

The HTML5 specification says the following about the behavior associated with details:

The user agent should allow the user to request that the details be shown or hidden. To honor a request for the details to be shown, the user agent must set the open attribute on the element to the value open. To honor a request for the details to be hidden, the user agent must remove the open attribute from the element.

There is nothing related to accessibility associated with the element. There’s nothing in the HTML5 specification about what user-initiated action each user agent will associate with the details element. Unlike a link (a), there is no actionable behavior associated with the details element. If, as is likely, the details behavior is only triggered by mouse clicks, we’ll have to attach a tabindex of zero(0) to the element, and add our own code to open and close the item, to make it keyboard accessible—if we can add this functionality, depending on how much control we can exert over details.

The examples I provided responded to both a click event, and a simple ENTER keypress event. Depending on the context of use, I can also add additional events. We don’t know what events we can attach to details, though, or which events we can intercept. We’re not even sure about what happens if we attempt to override the element’s default behavior, by manually assigning the open boolean attribute.

There’s no mapping, either, between the element and whatever accessibility API browsers support. We also have no way to attach existing ARIA roles and states with the element, because we don’t know if doing so could conflict with the default behavior— we just don’t have any input into, or control over this element.

So there is absolutely nothing accessible about the element. There’s not even the promise of accessibility— the element’s behavior is too vaguely defined yet inflexible, to enable even partial accessibility until each and every user agent implements whatever it deems appropriate. Considering the various ways in which we can implement a collapsible section behavior, we’re unlikely to ever have satisfactory accessibility with the element.

The details element is not user friendly, either. For the last decade, we’ve come to learn that when we access a web page with a user agent that doesn’t support JavaScript, or where JavaScript is disabled, whatever collapsed sections exist in the page should expand, by default. Such behavior is the result of a long campaign to incorporate good design concepts, among them the concept of progressive enhancement— design the page without JavaScript, first, and then add the JavaScript to enhance the page effects.

Now, because of introducing a declarative element such as details, when a person accesses a web site with both Flash and JavaScript disabled, they still may not see all of the page contents. This is counter to established practices and user expectations. Do we now have to insist that browsers provide a way to turn off declarative animations, in addition to JavaScript and Flash? If so, what happens if we turn off declarative animations for an element such as details, but keep JavaScript and try to manually manage the opening and closing of the element?

We also run into problems with being able to print pages that contain details managed content. According to Ian Hickson, the browser print page functionality is supposed to reflect the state of the page—printing out the details element contents if the element is open, not if it is closed[9].

Typically, custom print page functionality is dependent on turning off JavaScript, and either removing or replacing the stylesheet. Neither of these is an option for the details element. If a site provides custom print functionality, as many do (such as my own web sites, via a custom module), we’ll now either have to strip the details element out of the page and replace it with some other element, or use JavaScript to purposely open this element in order to print the contents. Again, we’re not sure what’s going to happen if we attempt to override default browser behavior using JavaScript.

Designers and web site owners are also going to have a challenging time integrating the element into a site’s design. As demonstrated with my examples earlier, I can style the label for my collapsible section anyway I want. I can also control the expanding and collapsing behavior: opening and closing the collapsed section slowly, or expand the section horizontally, rather than vertically. Other than some crude manipulation, such as changing background colors, we have no control of the design or behavior associated with the new details element. We don’t even have the option to change whatever icon is used to signal that the item can expand.

Now, some people may be aware of the limitations, but stress that lack of customization is a positive, rather than negative, aspect of details.

We can’t control the design, true, but the design will be consistent for the operating system. We can’t control the behavior of the new element, true, but then, we don’t have to have JavaScript to control the element, either.

However, the design consistency also differs by browser as well as operating system, and most sites prefer to have the same look and feel across browsers and operating systems. As for the necessity of having JavaScript, its use is so ubiquitous now, that Content Management Systems, such as Drupal, integrate it’s use by default[10].

Speaking of JavaScript, contrary to assertions about “poorly” performing JavaScript libraries that add a heavy burden on a site’s bandwidth, the popular JavaScript libraries are not only well tested, they’re also optimized and compressed to the point where most would probably take less bandwidth then the average image embedded into a web page. Even for mobile devices, the bandwidth burden will be less than the average phone application, eBook, or YouTube video.

Cost

Returning to the rationales summarized earlier, the only point where I and those who provide counter-proposals agree is that the collapsible section behavior is used frequently. Is frequency of use of this type of packaged behavior enough to implement the behavior as an element?

First, let’s take a look at the cost of not implementing this element.

Several years ago, when HTML4 was released, it might have made sense for behaviors such as details to be packaged into declarative elements. Support for JavaScript and CSS was relatively primitive, and completely inaccessible. We had few libraries that provided the functionality we needed, and none were integrated into the tools we used.

All of this has changed in the last decade. We’ve had new releases for both ECMAScript and CSS, and improved support for both in all of our browsers. With the addition of ARIA, we now have a way to incorporate rendering semantics into our applications—and ARIA support is being incorporated into all of the major JavaScript framework and UI libraries.

The cost to implement this functionality using existing tools has already been incurred. We’ve already paid the bill. Additionally, as my examples hopefully demonstrated, we can use this type of collapsible section behavior with a variety of web elements, for many different purposes, at no extra charge.

Now let’s look at the costs associated with adding the details element. Tools such as lint tools and validation tools have to incorporate functionality to cover the use of the new element—and considering the different ways in which we use collapsible elements, the probable misuse of the element. HTML editing tools have to incorporate support for the element, as well as providing preview functionality (it’s not a simple matter of just defining a new element). WYSIWYG tools have to find some way to not only incorporate an icon for the new element, but also the summary element, and do so in a valid manner. As has been noted elsewhere, the significant number of new elements in HTML5, and the vagueness of their definition, is already a cause for concern for WYSIWYG tool builders[11]. Browsers have to implement support for the new element, which adds to the complexity of the browsers, as well as providing another point of failure. This is especially true since we’re using declarative animation where it has never existed before.

Designers are going to have to figure out what they can or cannot do to style the element, and page authors and developers are going to have to figure out when it can be safely used, and how. Builders of tools that generate content, such as Drupal and WordPress, have to figure out if they need to incorporate support for the element into theme options or as components. Developers who provide print themes without having to use JavaScript, now have to use JavaScript to ensure the element’s contents are printed out. Books will have to be updated, tutorials re-written or created, examples and other documentation provided.

We have to also consider that by implementing one element specifically to emulate a JavaScript-enabled behavior, we’re opening the door to many more of these elements. In the notes related to the Accessibility Task Force decision to protest the change proposal to remove the details element, someone mentioned about not only implementing a details like element, but also implementing elements for other behaviors I’ve mentioned, such as accordion or tabbed page behaviors. The HTML5 editor may believe that something like a collapsible section should be created, but tabbed pages or accordions are “out of scope”, but the only criteria that seems to be used in determining which to create, and which to not, is the editor’s own opinion. This means that we could have potential explosive growth in new elements in future versions of HTML, when either the editor’s opinion changes, or, we have new and different editors.

Whether everyone agrees with implementing declarative elements for these higher-level behaviors or not, I believe there is some general agreement among all those who protest my proposal to drop details that a) it’s better to have declarative elements, and b) the costs are primarily to the browser implementors, without significant impact on other communities. The writers of the counter-proposal have stated that the only cost they see to the element is:

Each new element, attribute, and control is extra functionality for browsers to implement, and for HTML educators, including tutorials, to teach.

However, as I hope I’ve demonstrated, there are significant costs associated with each new element and attribute added to the HTML5 specification, and that the impact can be felt by a great number of web communities. The group may decide the cost is worthwhile in the end, but it should, at a minimum, be aware of the costs and impacts on on all of the communities.

The details element is worth the cost if we believe one thing: that web page authors, designers, and developers will use this new element over existing libraries and implementations. Considering the state of the art of this type of functionality today, and how long before this element could be used in the majority of web sites, and how limited we are with both the styling of the element and where and how we can use it, I find it unlikely that the element will achieve widespread use. I’m confident saying it is unlikely the details element will be used enough to justify its cost.

The details element provides too little in the way of new functionality, and what it does provide, it provides too late.

References

HTML5

Simplify

Post author By Shelley Powers
Post date March 30, 2010

At last count, I believe the HTML5 specification is adding 35 new elements, give or take a couple. That’s a lot of new elements. So what, we say. After all, it’s just a bit of text in a specification.

Unfortunately, new elements are more than just a bit of text. They have to be supported in all of the user agents, and they also have to be supported in any number of other applications, including HTML editors, Content Management Systems, validators, debuggers, and so on. A new element is a costly thing, so it needs to be a needed thing. The question is: do we need all of these new elements, and attributes?

It’s an odd thing, but people seem to have developed a disdain for the lowly div element. It’s not a meaningful element, we hear. We use terms such as divitus or some variation. Poor little play dough element.

Yet the div element was never intended to be anything more than a structural construct. It’s purpose was to be attached using the class attribute, styled using CSS, controlled with JavaScript, and given meaning with WAI-ARIA, RDFa, Microformats, and Microdata. Now, however, div is out, and article/section/footer/nav…are in.

Are we taking the right path with HTML5? It’s true that we can built expectation based on an element labeled nav or article that we can’t build on div elements with class names of “nav” or “article”. At the same time, though, adding new div elements with class names doesn’t require creating a new version of HTML, or require changes to browsers and other tools.

What kind of expectation can we build on these new elements? One expectation relates to the contents and structure. According to a blog entry written by James Graham, on the WhatWG weblog[1]:

HTML 5 introduces new elements like <section>, <article> and <footer> for structuring the content in your webpages. They can be employed in many situations where <div> is used today and should help you make more readable, maintainable, HTML source. But if you just go through your document and blindly replace all the <div>s with <section>s you are doing it wrong.

This is not just semantic nit-picking, there is a practical reason to use these elements correctly.

In HTML 5, there is an algorithm for constructing an outline view of documents. This can be used, for example by AT, to help a user navigate through a document. And <section> and friends are an important part of this algorithm. Each time you nest a <section>, you increase the outline depth by 1 (in case you are wondering what the advantages of this model are compared to the traditional <h1>-<h6> model, consider a web based feedreader that wants to integrate the document structure of the syndicated content with that of the surrounding site. In HTML 4 this means parsing all the content and renumbering all the headings. In HTML5 the headings end up at the right depth for free).

James even provides an example:


<body>
  <h1>This is the main header</h1>
  <section>
    <h1>This is a subheader</h1>
    <section>
      <h1>This is a subsubheader</h1>
    </section>
  </section>
  <section>
    <h1>This is a second subheader</h1>
  </section>
</body>

Which supposedly translates to the following navigational outline:

This is the main header
+--This is a subheader
    +--This is a subsubheader
+--This is a second subheader

Shiny newness…except…what about previous guidelines? As one person brought up in comments, what about the Web Content Accessibility Guidelines [2], which state to use H1-H6 to define the structure of the document?

Well, that’s old stuff. This is new stuff.

OK, it’s new, but is it better?

I look at the outline for one of my sites, which is based on the “old” XHTML+RDFa[3], and compare it with the outline for the HTML5 Doctor web site, which is based on the “new” HTML5 markup[4], using an HTML5 Outliner tool. Disregarding the different article counts, there is little different between the two. The behavior is exactly the same.

Now, it’s true, we could ask for a generic header element (<H>) and use it with section/article to create a web page with an outline five, ten, fifteen levels deep, but seriously, how useful is this? When I work on my books, we have several headers we can use to signify the depth of the section, but we’re discouraged from going beyond a depth of three levels. You can only break up your outline so much, before you make things worse.

I don’t want to just pick on section and article, or even pick on these elements. The point I’m making is that sometimes we can get so caught up in the shiny new that we don’t take time to think about what’s being offered, and to challenge it if all it does provide is new without also providing purpose.

References

[1] http://blog.whatwg.org/is-not-just-a-semantic

[2] http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H42

[3] http://missourigreen.burningbird.net

[4] http://html5doctor.com/

[5] http://gsnedders.html5.org/outliner/

HTML5

Issue 90

Post author By Shelley Powers
Post date March 30, 2010

Summmary

Summary: Remove the figure element.

Rationale

The following is the text for the initial bug[1] associated with this Issue:

Currently the HTML5 specification has an overly broad definition about what can be allowed in a figure element:

“The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.”

This is counter to understandings about figure in other businesses and environments, where figures are illustrative graphics of some form. In addition, this provides a confusing parallel in functionality between figure and aside, enough so that people are going to have a difficult time knowing which is which, and when to use one over the other. In fact, with this parallelism, we don’t need both.

All assumptions I have read on figure is people assume the element will contain a reference to an image of some form and a caption. Yet caption is optional, and it sounds like anything can be included in figure. The specification examples show a poem and a code block, in addition to an image.

The figure element either should be pulled completely, in favor of the aside element, or it needs to have a tighter focus in its definition. It should consist of a graphic element, which could be an svg element, a mathml element, an img, an object, or, possibly, a video. It should then have one other element, which will be the caption. Since this element won’t be a svg, mathml, img, object, or video element, it could be anything, including just a regular paragraph. In fact, a regular element styled using CSS would be the best option.

This change would remove any confusion about this element, and there will be confusion. It would also eliminate the problem with having to create a special caption element, just for figure, as discussed in Issue 83.

In a second comment to the bug, I also added the canvas element to the list of allowable elements. The Editor’s rationale for marking the original bug WONTFIX

Rationale: I actually agree with Shelley on this, and that’s what HTML5 used to say. However, it is one of the very few topics which got a _huge_ outcry from Web authors around the Web, demanding that <figure> be allowed to contain basically any flow content (including sections, headings, paragraphs, lists, etc). That’s why the spec says what it does now.

Originally, my interest was only in cleaning up the figure element; to make it more consistent with standard practice in the print world. The more closely I examined the element and the discussions about it, though, the more I felt that we would be better off eliminating the figure element altogether.

The reason for specialized figure handling in the print world is because of typographic convention. This doesn’t really apply in the web world, because we have elements that can group, CSS that can style, WAI-ARIA for accessibility and semantics, as well as other semantic options. If we want to move the figure away from the text, but still have the two associated, we can just by linking the two. In fact, we would have to anyway, because there is no way to associate a figure element with its text if the two are in separate contexts, unless they are linked in some way.

There’s a good reason for specialized figure handling in the print world, but not for web pages. Because we don’t have a good understanding of why we have figure, we can’t determine what it should contain. We only have to look at the discussions about what should be allowed within the figure element to discover that no one really has a clear idea of what this element is for, or how it will be used. Well, other than something with an optional caption, that is tangentially related to the content of the page (as if “tangentially” has a great deal of meaning in a web context, considering that anything can be tangentially related to anything else with the simple addition of a link).

The figure element, as defined in the HTML5 spec, is also a far different construct than what was originally intended. The figure element originated from discussions related to finding a way to attach a caption to an img element[2], somewhat like the caption we attach to tables, but allowing markup rather than just text like the table’s caption attribute. I’m not sure at which step in the evolutionary path it went from a caption to an img, to this all encompassing something with an optional caption we have today.

I did find emails from Michael Fortin[3][4] and Simon Peters[5][6], providing use cases for the figure element. Several of the use cases that Michael pointed out were to Apple online manual web pages. He classifies the code samples that Apple labels as listings, as figures. However, the Apple company itself, restricted the use of figure for illustrative images, only. For tables it used the moniker Table, for listings, Listing. As such, Apple’s own terminology undermines the credibility of these pages as use cases for allowing actual code samples as figures. More specific to the point of this change proposal, if we add a new element for figure, why not for listings, too? That’s also a separate typographical entity in the print world.

Other use cases provided ran the gamut from the pre element for ASCII art, to actual tables, though we already have a table construct in HTML. And when we try to limit what’s allowed, someone somewhere will dig up some actual use case online, somewhere, defending the particular use.

As can be seen, either we allow everything in the figure element in order to meet all possible sets of existing use cases online, in which case figure is really nothing more than a variation on the div element; or we restrict the element to a small subset of allowable elements, and continually fight the battle of, “Well, what about this? What about that?” All for an element that, in actuality, doesn’t provide much in the way of semantics or usefulness.

The figure element is really is nothing more than a grouping mechanism, as was noted back in the beginning of the discussion about the element[7]. So why don’t we use what exists now, rather than create something new?

I was reminded recently that the WAI-ARIA states and roles are useful beyond their primary task, which is provide information for screen readers such as JAWS and NVDA. Other “screen readers”, such as search web bots, like Google’s, can also make use of the semantic information they provide. Among the semantics we can define with ARIA is being able to assign an image role to a div element, and link the image’s caption to another HTML element.

As an example, in the WAI-ARIA 1.0 specification, there is an image listing that I modified, below:


<div role="img" aria-labelledby="caption">
  <img src="example.png" alt="Some descriptive text">
  <p id="caption">A visible text caption labeling the image.</p>
</div>

Compare with the figure element:


<figure>
<img src="example.png" alt="Some descriptive text">
<figcaption>A visible text caption labeling the image.</p>
</figure>

There is little different between the two, and the ARIA example has the added benefit in that it is implemented in many screen readers today. Best of all, there’s nothing about this example that disallows its use by search bots or other tools and applications, who can then attach the right caption for the element rather than have to scan the surrounding text to derive a caption, or using the alt text.

If the figure is located apart from the text that references it, giving the outer div element an id attribute allows us to link the figure in the text. If we don’t need a physical link, we can use terminology, such as Figure 1, Figure 2, and relate the text and the illustration using this approach. There is nothing about the figure element that changes how the text/illustration are connected—you still need to link the two, or use the caption, itself, to connect the two.

You don’t have to use an img element within the div element. You don’t have to use a div, either. For the pre/ASCII art use case, attach the role and aria-labelledby attributes to the pre element:


<pre role="img" aria-labelledby="caption">
...
</pre>

It’s also a simple matter to style whatever we use, too. For instance, a CSS setting for the img example could be the following:


[role="img"]
{
  margin: 10px;
  border: 1px solid #ccc;
}

[role="img"] p
{
  margin-left: 20px;
  font-style: italic;
  font-size: .8em;
  line-height: 1em;
}

We could also further annotate the element using one of the three available semantic annotation technologies available to us: RDFa, Microdata, and Microformats. In fact, we’re overrun with an abundance of semantic annotation capability—too much so to worry about creating single purposed elements supposedly for semantic reasons.

Details

Based on the March 4th HTML5 specification, remove Section 4.5.12, on the figure element. Also remove any additional references to the figure element. In addition, remove Section 4.5.13, on the figcaption element, and any reference to it, too.

Impact

Positive

This alternative to figure I’ve provided in this change proposal is a frugal one that serves the same purpose for multiple user agents, multiple audiences, and uses available technology and specifications. It allows people to create any form of illustration, and ensures they’re accessible.

Removing the figure element and associated figcaption element, helps trim down the overlarge number of elements that have been added with HTML5. Each new element we add to the specification has a related cost when it comes to implementation—not only across browsers, but also other tools, such as HTML editors, and HTML generation tools.

In addition, encouraging the use of existing HTML, CSS, and ARIA properties and attributes also encourages reuse over creating new, which should be a fundamental goal of this group. If there is a strong rationale for creating something new, and there really isn’t a good alternative, then we can feel justified in creating new elements. However, in the case of figure, as both Michael and Simon have pointed out, we’ve made do with what we have today. We can improve what we have with the addition of the ARIA states and roles, and ensure both a semantic and an accessible solution.

Negative

Change will require HTML5 editor time. As far as I know, there is no implementation of figure in browsers or other tools, and there is no dependence on it that I can see in web pages. There might have been some modification to validation tools to support the figure element.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-November/007859…
[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006828.html
[4] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-July/012194.html
[5] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008301…
[6] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-December/008302…
[7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-June/006822.html