The traditional, structured way to markup and delimit separate sections in SGML and XML is to put each part within its own container element. e.g.

<part>
  <p>part 1</p>
</part>
<part>
  <p>part 2</p>
</part>

From a structural point of view, this clearly indicates a certain separation between the two parts, whatever the actual container element or semantics may be.

However, there is an anomaly in all versions HTML and XHTML with some elements designed as separators, rather than container elements. Specifically, I’m referring to HTML’s hr and br elements, and XHTML 2’s proposed separator element. To separate one part from another, these elements are placed between the content, which some argue goes against the spirit of SGML and XML. e.g.

<p>part 1</p>
<separator/>
<p>part 2</p>

Tag Name

The XHTML 2 separator element has been renamed from HTML 4’s hr element. The reason for this is that the presentation of the separation is not always horizontal, and not always a rule. According to a recent presentation by Stephen Pemberton, the Japanese community were asking for a vr (Vertical Rule) element. He also provided some examples from different editions of the same book where, in each case, the presentation of the separator was different, but the semantics were the same.

In order to remove all presentational suggestion from the element name, and in an attempt to address the true structure of the construct, the element was renamed to separator. However, this name has been questioned because of its apparent spelling difficulty. It seems that ‘separator’ is often incorrectly spelt with an ‘e’ in place of the first ‘a’ as: ‘seperator’. There has been a suggestion for the tag name to be reduced to ‘sep’ to avoid all this confusion and make it easier to type.

However, regardless of the tag name’s spelling, the question still remains as to whether the name truly represents the elements semantics; or, indeed, whether it has any semantics at all, or if it’s just a place holder for a presentational construct.

Structure

Jukka Korpela has previously argued strongly against these empty separator-like elements in HTML, and suggested that the br element be replaced with a much more structured line element instead, and that the hr element be replaced with a similar structural equivalent. He compares hr with the original structure of the p element as a separator between paragraphs, rather than a container; and Unicode control codes; and explains why this structure is not appropriate in an SGML or XML context.

There is also the question of what exactly does it separate? In example 2 above, the separator element clearly separates part 1 from part 2. However, the separation is not always as clear. For example, if the separator were to be included within its own part, then the question of what it actually separates becomes a little more complex.

<part>
  <p>part 1</p>
</part>
<part>
  <separator/>
</part>
<part>
  <p>part 2</p>
</part>

It would appear that the intention of this markup structure is to markup the separation between parts 1 and 2. However, from a structural point of view, the separator element in this case really only serves to separate the content within the second part element. If the separator element is really intended to both structurally and semantically separate parts 1 and 2, then it would seem that the boundary of separation extends beyond the separator element’s parent, which really seems to break the tree-like structure of XML markup even more.

Now, you may be asking what possible reason there is that would require such a structure with any real XHTML elements; but take my word for it, as we will see later, this kind of structure is required in some circumstances, for the separator element.

Alternative Markup

This issue with br element has in fact already been addressed with the introduction of the l element in XHTML 2, but the issues with the hr and separator elements still remain. In essence, the hr element is the block-level equivalent to the inline br element; yet it is not quite so easy to replace it with a structural and semantic equivalent, as it is replacing br with l, because it is harder to define its semantics.

Examples 1 and 2 above are logically identical, in that they both mark up the separation between parts 1 and 2. They are clearly structurally different; but the question of semantics still remains. It has been argued that the structured, semantic equivalent already exists in XHTML 2 as the section element. For example, the following is structurally equivalent to example 1 and logically equivalent to both examples 1 and 2, but is it semantically equivalent to either?

<section>
  <p>part 1</p>
</section>
<section>
  <p>part 2</p>
</section>

Presentation

One of the arguments against the semantic equivalence of examples 2 and 4 is that example 2 typically results in some default presentation as an indication of separation between sections, which may convey some semantics to the reader. This indication is typically a horizontal rule, stars, or other graphical representation in a visual medium; a long pause in an aural medium, etc.

Although the presentation alone is not, in any way, a reason to retain any element in a semantic language – particularly if a non-presentational, well structured, semantic equivalent already exists – the issue of presentation is not simply about how it looks in this case; but the semantics that the presentation conveys to the reader, which makes it semantically different from other existing markup.

Semantics

As we have seen throughout this discussion, each issue comes down to the issue of semantics, and what the element actually means. One of the problems is with defining the semantics is that the definition was rather vague in HTML 2.0, and only became more so later. The definitions for the hr element in all versions from HTML 2.0 through to XHTML 1.1 and the separator element in the XHTML 2.0 draft are as follows:

Horizontal Rule: HR (HTML 2.0):

The <HR> element is a divider between sections of text; typically a full width horizontal rule or equivalent graphic.

Horizontal Rules (HTML 3.0 – Expired draft)

The <HR> element is used for horizontal rules that act as dividers between sections. The SRC attribute can be used to designate a custom graphic, otherwise subclass HR with the CLASS attribute and specify the appropriate rendering with an associated style sheet.

HR – horizontal rules (HTML 3.2)

Horizontal rules may be used to indicate a change in topic. In a speech based user agent, the rule could be rendered as a pause.

Rules: the HR element (HTML 4.0 to XHTML 1.1 (Modularization of XHTML))

The HR element causes a horizontal rule to be rendered by visual user agents.

The separator element (XHTML 2.0)

The separator element separates parts of the document from each other.

With such poor definitions, it’s easy to understand why there is such a debate over the element’s semantics, and why it is often viewed as a poorly structured, non-semantic, presentational element. In order to understand its true semantics, and how it differs from other elements like section, we must analyse its legitimate, non-presentational usage in the real world. There are two common use cases we will investigate, including separators used in books, and separators used to group menu items in a typical GUI.

Usage

Book Chapters and Topics

In books, and other similar publications, such separators are often used to indicate a minor change in topic, scene or perspective. These changes, or divisions, are usually smaller than a whole chapter and, in fact, a chapter may contain many such divisions with each separated visually with some kind of rule, stars or other graphical representation.

Compare this with the section element, which is designed to structure a document into sections – each with its own heading (in most cases). The sections delimited with the separator element tend not to have headings – they’re still related to the same section – but they do indicate a slight, yet related, change in topic. Thus, while both are similar, there is a semantic difference between the two.

Menu Items

For menu items, such separators usually group related items. For example, options to create, open and save documents are separated from those used to preview and print the document, yet they are still operations performed on the file as a whole, and therefore generally belong in the File menu. In this case, the separator doesn’t really indicate a change in topic, but rather a way to group related items. Using the separator element, this structure could be marked up as follows.

<nl>
  <label>Menu</label>
  <li>Item 1</li>
  <li>Item 2</li>
  <li><separator/></li>
  <li>Item 3</li>
  <li>Item 4</li>
</nl>

Note the similarity in structure to example 3 where the separator element is within its own separate container element.

It should be noted that there is another common method used to group related menu items with the use of submenus, which usually fly-out to the side of the parent menu item. For this reason, it is often believed that nested lists represent the semantics of submenus, while separators indicate the semantics of the lower-level grouping. However, as I will demonstrate, this is not always the case, and structures already exist to semantically markup both kinds of groupings without the use of a separator element.

Solutions

The first, and most often proposed, solution is to introduce a new container element for these purposes. The benefit is that the element will (hopefully) have well defined semantics and allow a UA to present it appropriately. However, the difficulty with this is that a new element that would be appropriate for use within a section would not be appropriate for use within a list, due to the differing content models and semantics of the seperation.

The next commonly proposed solution is for authors to include a class attribute on the elements that require separation and then use CSS to style them appropriately, such as with a border. While this solution is perfectly reasonable when the separation is purely presentational with no semantic meaning whatsoever, it is not suitable for the semantic cases discussed above.

If it were used for a semantic case, then it would be a case of moving the semantics out with the presentation (rather than separating) and actually depend upon the availability of stylesheets to accurately express the semantics. As a result, the document may inadvertently change meaning when stylesheets are disabled or unsupported.

Another solution is to make use of a semantic attribute on existing container elements, such as section, div or whatever else. Luckily, in XHTML 2, there already exists an attribute for the purpose of extending elements with more specific and well defined semantics, known as the role attribute.

Book Chapters and Topics

Using the example of the book chapters given earlier, a section element could be used to represent a chapter and div elements to represent the change in topic.

<section role="chapter">
  <h>Chapter Title</h>
  <div role="topic">
    <p>part 1</p>
  </div>
  <div role="topic">
    <p>part 2</p>
  </div>
</section>

Ordinarily, the div element is semantically meaningless; however semantics are added to it with the use of the role attribute in this case. Since the semantics of the role attribute and value would be well defined, unlike the class attribute, UAs may freely default to drawing a horizontal rule, or other presentation, between each topic; even in a non-CSS environment. Of course, authors may freely use CSS to alter this presentation as desired. The important point is that the semantics of the separation is retained, while providing a much more structured and semantic method.

Menu Items

Unlike books, the separation in the case of menu items generally doesn’t indicate a change of topic; but rather a method to logically group related items. This separation is still somewhat semantic – not entirely presentational – and, as such, requires structurally correct, semantic markup. This can be easily achieved using various kinds of nested lists.

In the following example, the nested unordered lists represent the same grouping achieved with a separator element, and the nested navigation list represents a sub menu.

<nl>
  <label>Menu</label>
  <li>
    <ul>
      <li>Item 1</li>
      <li>Item 2</li>
    </ul>
  </li>
  <li>
    <ul>
      <li>Item 3</li>
      <li>Item 4</li>
    </ul>
  </li>
  <li>
    <nl>
      <label>Submenu</label>
      <li>Submenu Item 1</li>
      <li>Submenu Item 2</li>
    </nl>
  </li>
</nl>

Conclusion

It should be clear that the structure of the separator element is not really appropriate for the tree-like structure of an XML document — it’s an anomaly introduced in early versions of HTML that is still hanging on by a thread. Regardless of what the element is actually called: hr, separator or even sep, the most important issue that needs to be addressed is its semantic definition, and thus whether the structure is really appropriate within a semantic language.

Only after clearly defining the intended semantics of the element can it be determined whether or not suitable alternatives already exist, and, if not, whether or not it is possible to apply the same semantics in a more well structured manner.

There are already elements in XHTML intended to markup sections and divisions within a document, as well as many other structures. In many of these structures, there may be reasons to logically, structurally and semantically group and/or separate sections within. However, because the semantics of the separation for one structure may differ from another, a single general purpose grouping or separation mechanism may not provide the required structure and semantics in all cases.

Where the separation indicates a change in topic, scene or perspective, the use of existing structural elements with a semantic attribute is a good, feasible solution. However, where the separation merely indicates groups of related items, such as in a list, then adjusting the markup structure may be all that is needed; perhaps combined with some additional semantic attributes as well.