Heading hierarchy - let's make it dynamic

Topics: General, Writing themes
Developer
Oct 19, 2011 at 6:58 PM

The problem

I see that the first heading (h1) is used in many occasions (like Widget.Wrapper.cshtml and Parts.RoutableTitle_Summary.cshtml).  Together that the header commonly has the title in an h1 quickly makes situations where there will be 3-6 h1-s on the page.

In my opinion there should be most of the time one h1 (the title of the page: in case of a Page this is directly the page title; in the case of a blogpost the title of the post), and all subsequent titles should be of lower level. In addition to this the problem of breaking the hierarchy quickly arises with list containers: for example the Blog page has a title (the name of the blog) of h1, then the individual blogposts have a title too, all with h1. The hierarchy of headings is not present.

The html specification is quite loose about headings, so it could be of course a subject of debate what h1 really should be but I think we can all agree that the levels of headings should reflect the hierarchy of the content.

How it should work

The level of headings is therefore the matter of position (like whether the item is inside a container or not) and should be dynamic, not hard-coded. As a quick example of how placement-sensitive headings could work, take again the example of blogs (where the level of list items are the level of headings, respectively, not necessarily the sequential order of elements!):

Example one:

  • Stephan's blog
    • My last day
      • My morning
      • My evening
    • My last week
      • My monday
      • My sunday
    • ...

The same blogposts if listed in a sidebar widget on a page (not that here are to h1-s):

  • About me
    • How I was born
    • My childhood
    • Teenage...
  • Recent blogposts
    • My last day
    • My last week

And one blogpost on an individual page:

  • My last day
    • My morning
    • My evening
      • Comments

Since summaries don't contain markup, and therefore no headings are present, the problem can be narrowed down to blog post titles. However I think we should really find a general solution, fitting all sizes.

A possible solution

Dynamic headings could be achieved with custom html helpers that would always generate the appropriate level of heading. It's a question, however, how the system should take track of headings added and adjust the level of headings.

What quickly comes to my mind is to use the tree of shapes: we can safely assume that if a header is in a shape that is contained by some other shape than it should be of lower level than its parent (i.e. the level of headings should reflect the depth of a node in the shape tree, but the heading's level is most likely not the same as the depth of the shape it is in). Heading levels should therefore increment with shape depth. So for example take this actual shape tree I got from the visualization of the shape tracer (excerpt, shapes containing a heading outlined bold):

  • Zone[Content]
    • Content (a blog)
      • Parts_RoutableTitle
    • List (posts)
      • Content
        • Parts_RoutableTitle_Summary
      • Content
        • Parts_RoutableTitle_Summary
  • Zone[AsideSecond]
    • Widget (in Widget.Wrapper)
    • Widget

All headings were h1-s. This with dynamic headings could look like the following:

  • Zone[Content]
    • Content (a blog)
      • Parts_RoutableTitle H1
    • List (posts)
      • Content
        • Parts_RoutableTitle_Summary H2
      • Content
        • Parts_RoutableTitle_Summary H2
  • Zone[AsideSecond]
    • Widget (in Widget.Wrapper) H1
    • Widget H1

There comes the problem how the system should handle user-defined headings (like ones written in html widgets or blogposts). The easy way would be to assume that these headings will only show where the user wants them to (e.g. headings in blogposts won't show in summaries anyway), so we shouln't worry about them. Another approach would be to somehow implement dynamic headings with user-defined headings too, maybe with the usage of the newly introduced tokens, but I don't have enough knowledge to judge that.

Quick solution without over-engineering what could be simple and by not taking the complicators' gloves

Let's change that h1 to h2 in /Core/Routable/Views/Parts.RoutableTitle_Summary.cshtml and instruct users to start with h2 when writing content :-). Should I submit a patch? :-)

Coordinator
Oct 19, 2011 at 7:39 PM
Edited Oct 19, 2011 at 7:50 PM

Well, no :) There is actually no debate to be had here as the HTML 5 specification is pretty clear on the subject:

"Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level"
http://dev.w3.org/html5/spec-author-view/headings-and-sections.html
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections

Well, in fact I see where you're getting at but couldn't that result be obtained in your theme?

Developer
Oct 19, 2011 at 7:48 PM
Edited Oct 19, 2011 at 7:52 PM

My bad... I totally missed the sectioning :-D. Then there is really nothing to change here.

Coordinator
Oct 19, 2011 at 7:50 PM
Edited Oct 19, 2011 at 7:51 PM

Yeah, each of those post summaries are like mini-documents with their own local navigation...