Bruce Lawson recently asked for ways to style a definition list in the common glossary format. This is one way to do it.

Bruce’s original post – css challenge – describes what he is after: a “glossary style” appearance with the term on the left and the definitions on the right. Some terms will have multiple definitions, definitions of varying length, and each new term should appear on a new line. A definition list is semantically correct for this kind of information, so there was to be no fiddling around with the HTML, and the browser requirements were for it to work in all modern browsers and IE 6+.

You can skip straight to the demo where some additional classes are included in the HTML in order to highlight each term-definition association.

The basic HTML

The basic HTML structure is a simple definition list and nothing more. There are some short, long, and multiple definitions for each term.

<h1>Styling definition lists</h1>
<dl>
  <dt>Cheese</dt>
  <dd>
    <p>Velit esse cillum dolore in reprehenderit in voluptate duis aute irure dolor. Consectetur adipisicing elit, excepteur sint occaecat sunt in culpa. Velit esse cillum dolore eu fugiat nulla pariatur. Ut aliquip ex ea commodo consequat.</p>
    <p>Mollit anim id est laborum. Ut enim ad minim veniam, consectetur adipisicing elit, ullamco laboris nisi. Lorem ipsum dolor sit amet, sunt in culpa quis nostrud exercitation.</p>
  </dd>
  <dd>yummy!</dd>

  <dt>Building flexibility through spreading knowledge and self-organization, exploiting the productive lifecycle to experience a profound paradigm shift. Through the adoption of a proactive stance, the astute manager can adopt a position at the vanguard.</dt>
  <dd>balderdash</dd>;
  <dd>poppycock</dd>

  <dt>Aardvark</dt>
  <dd>never hurt anyone</dd>
</dl>

The styles

In order to get the required appearance in all browsers I had to use negative margins and a few conditional styles to get IE7 and IE6 to play along.

For the purposes of the demo I’ve placed all the styles in <style> blocks in the head of the document.

<style>
   dl {padding-left:300px;}
   dt {clear:both; float:left; width:260px; padding:10px; margin:0 0 2em -300px; font-weight:bold; color:#686663;}
   dd {float:left; width:100%; padding:10px 0; margin:0 0 2em;}
</styl>
<!--[if lte IE 7]>
<style>
   dt {display:inline; margin-bottom:0;}
   dd {float:none; width:auto;}
</style>
<![endif]-->

That’s it. The widths of the <dt> can be set in ems or percentages if the layout requires. The complete code is available in the demo and you are free to use this code.

In the last few months there has been increased discussion about some of the new elements that have been introduced in the HTML5 draft specification. This entry is primarily a counter argument to some of the comments that I disagree with.

The most recent and high-profile comments in regard to parts of the HTML5 specification come from The HTML5 Super Friends in an article entitled Guide to HTML5 Hiccups. It lays out their concerns with the HTML5 draft specification as it stood at the time of its writing and I am largely going to focus on the issues they have discussed.

The article and section elements

The first argument that I disagree with is that the article and section elements are redundant and, therefore, that the article element should be dropped.

article and section are identical except that article allows a pubdate attribute. We would suggest that article be dropped and section be adapted to allow an optional pubdate attribute or, even better, more explicit metadata.

The article and section elements are not identical according the to HTML5 draft specification. Here is what it says about the section element as of 13 September 2009:

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Now contrast that with what it says about the the article element:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, application, or site.

An article element is “independent” in the sense that its contents could stand alone, for example in syndication, or as a interchangeable component on a user-configurable portal page.

That is a clear distinction that resists the reading of article and section being “identical”. The article element has a specific purpose: to mark parts of a document that form an independent composition that may be appropriate for syndication. It is a special kind of sectioning element that performs an essential role that is lacking in the semantics of the generic section element. This generic element serves only to thematically group content. That grouping may occur at the document level, within an independent article, or within a footer.

The article element has unique semantics and practical use. There is a fundamental conceptual difference between stand-alone compositions and sections of compositions, documents, or pages and this difference should be recognised and catered for in the specification. Websites regularly employ microformats and you don’t have to look far to see independent compositions currently marked up with class="hentry" or find links to individual blog comments and twitter updates. There is clearly a need for an easy way to define independent compositions and that is met with the introduction of the article element in HTML5.

What may be needed is a stronger clarification and definition of the article element to minimise the potential for this distinction to be overlooked and to highlight the differences from a generic document section.

The hgroup element

The hgroup element is a relatively recent addition to the draft specification. It is defined as serving a fairly specific purpose:

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

The element works to associate headings together so that the highest ranked heading descendant (if present) of the hgroup element is used as its text in document outlines and summary. Other heading descendants are treated as subheadings and are left out of outlines.

The HTML5 Super Friends have this to say about the hgroup element:

We don’t see the added value of this element and would instead add a boolean attribute to the heading element which allows content authors to specify if that particular heading should be included in the outline.

Bruce Lawson has similar concerns and proposes another alternative – removing the need for a wrapping element and defining a new element specifically for marking up subtitles:

I agree that hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use

<header>
<h1>My blog</h1>
<subtitle>My wit and wisdom</subtitle>
</header>

as I think that;s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.

I disagree with these criticisms of the hgroup element and consider the proposed alternatives to be more problematic, less intuitive, less flexible, and further removed from the way in which authors currently markup subheadings.

The way that many authors are currently marking up subheadings is by using headings of various ranks and in various orders depending on whether the subheading or qualifying heading needs to appear above or below the main page heading. A subheading is still, conceptually, a heading of sorts and it cannot be accurately marked up with a paragraph or any other currently available element.

Allowing the addition of a boolean attribute to heading elements has several problems.

1. A boolean attribute may be less intuitive for authors than the hgroup element. The hgroup element relies upon and produces an association between all the headings it contains. Since headings and subheadings occur together and derive their meaning from each other, it is semantic to wrap these headings in an element. We know that the highest ranked heading contains the string to be used in the outline and that the other headings serve as ranked subheadings to this primary heading. A boolean attribute is only associated with the element that it is a part of. We can create no association between the element and adjacent elements. This is related to the next issue.

2. The hgroup itself acts as heading content while a boolean attribute would act only to remove headings from the outline. The hgroup element only removes the descendant headings that are those not of the highest rank. The boolean attribute shifts the burden onto the author to decide which headings should be marked for removal from the outline, rather than providing an element to wrap a collection of headings without authors having to be concerned with (or aware of) issues of outlining.

What about Bruce Lawson’s idea for a subtitle element? I believe that, irrespective of the what this element were actually called, it suffers from similar problems to the idea of using a boolean attribute. There is nothing to prevent the use of a subtitle element away from a heading, it creates no association with other elements, and it does not allow for ranking of subheadings.

One of my key points in relation to criticism of the hgroup element is that subheadings draw their meaning from context. A subheading (as opposed to a section heading) is only a sub-heading if it is associated with a higher ranking heading. Remove the higher ranking heading and what was once a subheading is likely to be understood as a heading.

The strength of the hgroup element over the two alternative suggestions I have referenced is that it is the only proposal that defines a subheading as contextual. I think that it is the most intuitive proposal (although perhaps none of them are particularly inuitive) – the name of the element is self-descriptive and encapsulates the contextual relationship and adjacent positioning of its child elements — and matches most closely with the way that subheadings are currently marked up on many websites.

The aside element

The HTML5 Super Friends are of the opinion that the aside element is not worth including in the specification:

The use cases for aside are too limited to warrant its inclusion in the specification. We were also concerned about potentially duplicating content within an aside.

However, the specification itself provides some fairly compelling uses for the element:

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

Authors might use the aside element for their blogrolls, for marking up adverts ranging from google ads on blogs to large banners on enterprise websites, for expanding on themes within an article or providing an extended definition of a term, for pull quotes, and anything else “tangentially related to the content around the aside element, and which could be considered separate from that content”.

Most of these uses would not involve duplication of content. Using the aside element for pull quotes would produce some instances of content duplication. However, this is not really a problem for users who are used to content being duplicated in this way in newspapers and magazines. It would not take much for search engines to adapt to deal with short amounts of duplicate content contained within an aside either. While I appreciate the point about duplicate content I’m not yet convinced that it is actually problematic.

The legend element

The current specification defines the legend element as providing an explanatory caption for the contents of its parent element. The parent element may be a fieldset, figure or details element. However, Remy Sharp‘s article entitled legend not such a legend anymore shows why it is not practical to use legend for the new elements details and figure – because it is not backwards compatible with current browsers and effectively unusable outside of a fieldset because of the inability to style the element.

In this case, forging a new element is most appropriate rather than trying to use an element like label which will only create confusion with little advantage.

Summary

I have discussed my reasons for disagreeing with certain feedback on the HTML5 draft specification. I have yet to be convinced that the article, hgroup, or aside elements should be dropped from the specification because it seems to me that they have necessary uses and advantages over alternatives.

Over the weekend two new HTML5 elements – summary and figcaption – were added to the draft specification. The introduction of summary and figcaption marks the acceptance that new elements are needed to act as captions or legends for the details and figure elements. The addition of the figcaption element finally begins to clear up the difficulty in marking-up figure element captions and looks to cement the place of the figure element in the HTML5 specification. The summary element does much the same for the details element but the very nature of the details element itself means that its future is not yet clear.

The figcaption element

This new element acts as the optional caption or legend for any content contained within its parent figure element.

If there is no figcaption element within a figure element then there is no caption for the rest of its content. If there is a figcaption element then it must be the first or last child of the figure element and only the first figcaption element (should there be more than one child figcaption of the parent figure element) represents a caption.

The figure element is used to mark up any self-contained content that may be referenced from the main flow of a document but could also be removed from the primary content (for example, to an appendix) without affecting its flow. This makes it suitable for various types of content ranging from graphs and data tables to photographs and code blocks.

<p><a href="#fig-ftse">Figure 1</a> shows the extent of the collapse in the markets and how recovery has been slow.</p>

<figure id="fig-ftse">
  <figcaption>Figure 1. The value of the FTSE 100 Index from 1999&ndash;2009.</figcaption>
  <img src="ftse-100-index-graph.jpg" alt="The index hit a record high at the end of 1999 and experienced two significant drops in the following last decade.">
</figure>

<p>This latest financial crisis hasn't stopped Alex from writing music and his latest track is actually worth listening to.</p>

<figure>
  <audio src="what-am-i-doing.mp3" controls></audio>
  <figcaption><cite>What am I doing?</cite> by Alex Brown</figcaption>
</figure>

The creation of the figcaption element is an important step forward for the HTML5 draft specification as it finally provides a reliable means to markup the caption for content that is best marked up as a figure. Previous attempts to use the legend element, the caption element, and the dt and dd elements had failed due to a lack of backwards compatibility when it came to styling these elements with CSS.

The summary element

This new element represents a summary, caption, or legend for any content contained within its parent details element.

The summary element must be the first child of a details element and if there is no summary element present then the user agent should provide its own. The reason for this is because the details element has a specific function – to markup additional information and allow the user to toggle the visibility of the additional information. Although it is not specified in the specification, it is expected that the summary element will act as the control that toggles the open-closed status of the contents of the parent details element.

<details>
  <summary>Technical details.</summary>
  <dl>
    <dt>Bit rate:</dt> <dd>190KB/s</dd>
    <dt>Filename:</dt> <dd>drum-and-bass-mix.mp3</dd>
    <dt>Duration:</dt> <dd>01:02:34</dd>
    <dt>File size:</dt> <dd>78.9MB</dd>
  </dl>
</details>

The introduction of the summary element seems to secure the future of the details element and the new behaviour that it affords, for now. When user agents begin to add support for the details element you won’t need JavaScript, or even CSS, to have expanding or collapsing sections in an HTML document.

The future of the details element

There will continue to be some debate over the inclusion of behaviour in an HTML specification especially given the widespread use of JavaScript to provide the expand-collapse functionality that details describes.

The details element writes some quite significant behaviour into an HTML document and I can see it being abused to provide generic expand-collapse functionality throughout a document. It is also not entirely clear what purpose the details element actually serves other than being an attempt to bypass the need for JavaScript or CSS to expand or collapse sections of a document.

There has been a general softening of the rough distinction between content, presentation, and behaviour. JavaScript libraries are being used to patch holes in browser CSS and HTML5 support, the CSS3 modules introduce plenty of behaviour that was previously only possibly with JavaScript, and the HTML5 specification is also introducing functionality and behaviour that previously required the use of JavaScript.

The future survival of the details element, and the behaviour associated with it, may well depend on browser implementations and author applications over the coming months.