I began this post as a WordPress “private post” to test header and list formatting and fonts as I resuscitated my previously-moribund personal blog. I had used a similar “reference” post at Case Western’s law library as an “exhibit,” along with an in-house style guide used by our authoring librarians, to harmonize the ways that we used limited HTML within the content we wrote, and to demonstrate the output authors could expect from the website’s CSS style sheet.
But I modified the original “heading test” private post that I started, to add some comments on the use of structure internal to content units (like blog posts or research guides) commonly written by librarians, and am publishing this post. I’ve also reflected on the possible differences in approaching page structure in HTML5 contexts versus “legacy” HTML page structures. This is a WordPress site, as is the comprehensive law library website that I have developed (lawlibrary.case.edu). But nothing here, except perhaps for occasional “post” or “page” nomenclature, would be limited to WordPress-based sites.
The title of this HTML5 <article> element (this blog post) is an H1.
Let’s talk library website headings.
The above was an H2 within an HTML5 <article>
It is used to identify a major content sub-division — here within a “post” or a “page,” the major default content units in the WordPress content-management system (CMS). On this site, these post-or-page H2 headings are large and in a heavier-than-normal (Benton Sans “medium” as opposed to “regular”) font weight.
This mark-up, using an H1 for the <article> level title and an H2 for the major sub-units therein, conforms to the HTML5 Document Outline specification. Here, each sectioning element (header, article, etc.) is treated as communicating structure, so the fact that this post is an <article> entitles it to have its own H1 (the name of the post) and all other heading elements. This remains transitional, and controversial. The W3C itself points out that an algorithm to parse the HTML5 outline model is not yet implemented in browsers or other user agents that parse page content, and that authors should still convey overall page structure using heading rank. I’m still inclined to believe that for posts on blog-type sites, like this, it will work out okay even in this moment of transition — index and archive pages, or any other page configuration combining multiple <article> units written to be semantically autonomous units will indeed have multiple H1 elements, and therefore multiple H2 (etc.) elements that are not actually nested within the same logical structure. But a single post or single page type of display should still deviate only modestly from the old-style HTML4 structural logic. The main departure from traditional practice on those pages will be the inclusion of an H1 for both the site title and the title of the specific content article. The consensus, as I understand it, is that this is at worst a very minimal impediment to search engines, and also to screen readers or other tools that interpret page structure. The absence of any real (to say nothing of widespread) implementation of the HTML5 outlining model might, however, have more significant implications for how navigational, sidebar, additional-content asides, and other structures on complex websites (like main law school or law library websites) should be marked up.
Subheadings: This is an H3
In the past, such as when we launched lawlibrary.case.edu, I’ve specified H3 headings for use as “main” headings inside of the individual posts or pages authored by my colleagues, on the assumption that the name of the post and the site title get the H1 and H2. This was based on conventions for page structure and how best to convey the logic of a page to browsers, screen-reading software (as for the visually impaired), and search-engines or other tools that parse and map web content. As this site aims to more fully embrace the HTML5 specification, there will be H1 titles for each post, and H2 main headings within posts. (Therefore the heading tiers effectively move “up” one and H2, rather than H3, can be used for major sub-units of content within a page or post.)
Typographically, on this site H3 is also a large heading in Benton Sans but at a regular font weight.
In the design of lawlibrary.case.edu individual page or post views used the H1 for the title of the post (to make the subject matter the top priority and the foremost thing we communicated to search engines or other “computer readers”) and H2 for the name of our website. This left the array of headings available to content authors limited to H3 through H6 elements. These were specified and described in both a style guide document shared with all of the librarians who write for the website, and in a WordPress private post that serves as a template and demonstration of how headers look and function in a document as displayed according the the law library’s CSS.
On lawlibrary.case.edu, the front page and index-type pages (various URLs that display titles of or partial contents from other pages) use H1 for the title of the library’s overall website, and H2 headers for their own post or page titles.
Further down the tree
That was an H4. Here is a short paragraph of text under the H4. These headings, on this site, are in small-caps with serifs (Benton Modern) and slightly larger than regular text. Because many browsers do not support the OpenType features for small-caps, there is a cheat that will use the small-caps-only font set from the similar Latin Modern free font if “@supports” can’t detect support for font-feature-settings. Fortunately, the set of browsers that implements @supports in CSS overlaps very closely with the one of browsers supporting OpenType “smcp” small-caps. Small caps and all caps were a bugaboo of ours when developing the Case Western library site. While print legal typography makes extensive (and idiosyncratic) use of small-caps in citations, legal writing on the web seems to dispense entirely with this Bluebook-driven convention and the discussion among the web-developer community and general-interest typography enthusiasts, even when exercised about “true” small capitals, seems to focus on different uses of them than the lawyers Bluebook-driven citation practices. On lawlibrary.case.edu we wanted to use small-caps (along with other conventions) to make our website look more like a “real publication” (i.e. hew closer to the Bluebook rules for law journals and publications rather than those for filings). We did this initially with “fake” small caps (simply down-scaled from regular caps) using the CSS font-variant property, and then adopted a font (borrowed from our very
<href=”http://lawlibrary.case.edu/2012/11/09/new-law-review-format-on-display-at-circ-desk/”>typography forward Law Review that included true small caps.
That was an H5. It is ever so very slightly larger than regular post/page text. And italic. In Benton Modern Italic.
This is an H6
It is slightly smaller than normal text. In Benton Sans RE. And in all true capitals (text-transform to uppercase).
H6 is as far as they go. And it is hard to see how any given <article> container would ever need to go farther, or on a site like this, this far. From my experience editing colleagues research guides at
<href=”http://lawlibrary.case.edu”>lawlibrary.case.edu, however, I know that individual pages can end up having pretty complex structures and hierarchies, especially where they are research guides or “pathfinder” type resources that emphasize listing/linking a lot of resources in a structured way rather than taking a more “narrative” or prosy approach. Although there we were limiting ourselves to H3 through H6 within the post, so this H6 is technically a level “deeper” than we could get in the structure of that site. If H6 wasn’t enough, we resorted to techniques like “bolding” or italicizing list elements to have heading-like behavior go “really deep” into a structure.
Using lists and nested lists
Lists can be nested, and are another really important way to communicate hierarchy within a post or page. List mark-up can be tricky and it is important to play close attention when communicating structure by nesting lists within each other. There may be another post in “lists for librarian authors on the web” because a lot of the things we write are really lists — bibliographies, for example. But that will wait for another day.
- Now. This is an un-ordered list.
- Item 1
- Item 2
- Item 3
This item has sub-items
- Nested item 1
- Nested item 2
- Item 4
List formatting can accomplish a lot. At a basic level, CSS can easily remove “bullets,” so a sense of how word processors or other familiar tools like to format lists is no reason to insist on avoiding list-structured mark up for content that is, in fact, logically a list.