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.

This site has been written in HTML5 and used to use WordPress to manage the content. I’ll explain why I used HTML5, describe the structure of the theme templates, and show some of the ways I tried to tame WordPress’s tendency to add mess to the source code.

As this is my personal site I wanted to experiment with using HTML5, CSS3, and WAI-ARIA. All these documents are currently working drafts and subject to change. However, the web documents and applications of the future are going to be written in HTML5 and I wanted to see the benefits of using it to markup static documents. Using CSS 2.1, let alone the CSS3 selectors and properties that some browser vendors have implemented, has many advantages for controlling the presentation of semantically coded documents. For this reason I am not going to avoid using basic CSS 2.1 selectors just to faithfully reproducing this site’s design in IE6. However, I have tried to accommodate IE 7 and IE 8 users by using an HTML5 enabling script so that the new HTML5 elements can be styled in those browsers if users have Javascript enabled.

HTML5 templates

I started with a static prototype of this site developed on my local server. WordPress makes it very easy to create your own templates and, therefore, it is no problem to use HTML5. This theme only has 3 main templates: index, single, and archive. There are of course templates for 404s, attachments, comments, etc., but I won’t discuss them as they are all based on the 3 main templates. All the templates include ARIA roles as an accessibility aide.

The single.php template has this rough structure:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title></title>
  <link rel="stylesheet" href="default.css">
</head>

<body>
  <header role="banner"></header>
  <nav role="navigation"></nav>
  <article role="main">
    <header>
      <time datetime="YYYY-MM-DD"></time>
      <h1></h1>
    </header>
    <footer></footer>
  </article>
  <nav></nav>
  <aside role="complementary"></aside>
  <footer role="contentinfo">
    <small></small>
  </footer>
</body>
</html>

The first line of the document is the HTML5 DOCTYPE. The new <article> element contains the content of each post. The same structure is used for the index.php template except that there are several articles displayed on each page and the ARIA role value of main is not used. In contrast, the archive.php template houses all the article excerpts in a <section> element with the ARIA role of main because the list of archived posts is itself the main content of the document.

A clean theme

WordPress tends to add classes, elements, and other bits of code in certain places. I haven’t used any of the WordPress functions that add class names to the body and to elements wrapping a post and also wanted to avoid cluttering the source code with any other unnecessary markup. This required a bit of fiddling around with the theme’s functions.php file. I’m not a PHP developer so this might not be pretty!

Removing actions from wp_head()

WordPress has a hook called wp_head that sits in the header.php of most themes. To avoid it inserting unwanted code into the <head> of the document I used the remove_action function to disable the functions that were responsible. The following code was added to the functions.php file of my theme:

// Remove links to the extra feeds (e.g. category feeds)
remove_action( 'wp_head', 'feed_links_extra', 3 );
// Remove links to the general feeds (e.g. posts and comments)
remove_action( 'wp_head', 'feed_links', 2 );
// Remove link to the RSD service endpoint, EditURI link
remove_action( 'wp_head', 'rsd_link' );
// Remove link to the Windows Live Writer manifest file
remove_action( 'wp_head', 'wlwmanifest_link' );
// Remove index link
remove_action( 'wp_head', 'index_rel_link' );
// Remove prev link
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 );
// Remove start link
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 );
// Display relational links for adjacent posts
remove_action( 'wp_head', 'adjacent_posts_rel_link', 10, 0 );
// Remove XHTML generator showing WP version
remove_action( 'wp_head', 'wp_generator' );

Source: WPEngineer.com: Cleanup WordPress Header

Removing an empty <span>

If you want to create excerpts you can either write them into the excerpt box or use the <--more--> quicktag in the WordPress editor. I just wanted the first paragraph of my posts to be used as the excerpt and so using the in-editor tag was the most practical approach I was aware of. However, when you do this WordPress will insert an empty <span> in the post’s content. This element has an id so that the area following the excerpt can be targeted by “more” or “continue reading” links. I removed both the empty <span> and the jump link by adding the following code to the functions.php file of the theme:

// removes empty span
function remove_empty_read_more_span($content) {
  return eregi_replace("(<p><span id="more-[0-9]{1,}"></span></p>)", "", $content);
}
add_filter('the_content', 'remove_empty_read_more_span');

Source: Ganda Manurung: Remove Empty Span Tag On WordPress

// removes url hash to avoid the jump link
function remove_more_jump_link($link) {
  $offset = strpos($link, '#more-');
  if ($offset) {
    $end = strpos($link, '"',$offset);
  }
  if ($end) {
    $link = substr_replace($link, '', $offset, $end-$offset);
  }
  return $link;
}
add_filter('the_content_more_link', 'remove_more_jump_link');

Source: WordPress Codex: Customizing the Read More

Displaying images in the excerpt

For posts that display nothing but a photograph (yes, they will be shit but I’m hoping it gets me using my camera a bit more often) I wanted the image to show up in the archives. Equally, if the first paragraph of a post contained a link I wanted that to be preserved. The default the_excerpt() template tag doesn’t allow for this so it needed some modifying. I added a new function, which is just a modified version of the core excerpt function, to the functions.php file and then made sure that the template tag executed this function rather than the one contained in the core WordPress files.

function improved_trim_excerpt($text) {
   if ( '' == $text ) {
      $text = get_the_content('');
      $text = strip_shortcodes( $text );
      $text = apply_filters('the_content', $text);
      $text = str_replace(']]>', ']]>', $text);
      $text = strip_tags($text, '<p><img><a>');
      $excerpt_length = apply_filters('excerpt_length', 55);
      $words = explode(' ', $text, $excerpt_length + 1);
      if (count($words) > $excerpt_length) {
         array_pop($words);
         array_push($words, '[...]');
         $text = implode(' ', $words);
         $text = force_balance_tags($text);
      }
   }
   return $text;
}
remove_filter('get_the_excerpt', 'wp_trim_excerpt');
add_filter('get_the_excerpt', 'improved_trim_excerpt');

Source: Aaron Russell: Improving WordPress’ the_excerpt() template tag

Conditional next/prev links

I prefer not to have empty elements in the markup and so I needed a way to conditionally insert the “Older entries”, “Newer Entries”, etc., links into templates. The solution I’m using here, which isn’t perfect, is to add this to functions.php:

function show_posts_nav() {
  global $wp_query;
  return ($wp_query->max_num_pages > 1);
}

Source: Eric Martin: Conditional navigation links in WordPress

And then to wrap the navigation markup in the templates with the following:

<?php if (show_posts_nav()) : ?>
<nav>
   <ul>
      <li><?php next_posts_link('&#171; Older Entries') ?></li>
      <li><?php previous_posts_link('Newer Entries &#187;') ?></li>
   </ul>
</nav>
<?php endif; ?>

Summary

It’s fairly easy to create a simple site with HTML5 and to use WordPress to deliver it. At the moment there are issues with Internet Explorer because you cannot style HTML5 elements unless you use Javascript. However, HTML5 redefines the meaning of certain elements (such as <dl>, which has become a more versatile “description list”) and allows block elements to be wrapped in a link. Therefore, there is still benefit in using the HTML5 DOCTYPE even if you do not make use of the new elements.

Further reading

1. HTML5 working draft
2. HTML5 differences from HTML4
3. Accessible Rich Internet Applications (WAI-ARIA) 1.0

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.

White, Ellen, 1978- author

Beal, Timothy K. (Timothy Kandler), 1963- author

Russell, Andrea, author

Gurses Tarbuck, Derya, author

Kilroy, Gerard, 1945- author

Spinks, Bryan D., author

Bastow, Sarah L., author

Hughes, Michael, 1961- author

Weaver, John, 1980- author

Stefan, Patrick G., author

Fox, Arminta M., author

Schneider, Floyd, author

Montero, Roman A., author, translator

Furlong, Dean, author

Powell, Mark Allan, 1953- author

Kloppenborg, John S., 1951- author

Thiselton, Anthony C., author

Adewuya, J. Ayodeji, 1951- author

Wink, Walter

Campbell, Joseph, 1904- author

Riches, Tanya, author

Tyson, Paul G., author

Hunt, Laura J., author

Arvidsson, Stefan, 1968- author

Sehested, Nancy Hastings, author

Carter, Warren, 1955- author

Hall, Crystal L., author

Wright, Arthur M., author

Nir, Rivḳah, author

Chilton, Hugh, author

Wire, Antoinette Clark, author

Cobb, Christy, author

Eikelboom, Alexandria, 1987- author

Archer, Kenneth J., author

Holland, Tom, author

Roth, Dieter, author