The Curious Case of Breadcrumbs in HTML
Post from October 3, 2013 (↻ June 1, 2020), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.
We had an interesting thread about breadcrumbs on W3C’s public-html the other day. At first just targeting delimiters (greater thans are not so great *), it spawned a debate about the appropriate markup. I dreaded the subject as much as I welcomed it. I dreaded it because the topic comes up again and again; I welcomed it so to maybe come to a resolution on a W3C list.
We don’t have such a resolution yet but I like to use the occasion to lay out my own view on breadcrumbs in HTML.
The matter has always looked simple to me †. There is no dedicated breadcrumb element, like
<breadcrumb>. The only elements remotely adequate then were list elements, but they appear out of the question for reasons I share in a second. Which has, prior to HTML 5, left only one element, the one that’s been designed to cover cases for which there is no dedicated markup:
<div>, to be used with an ID like “breadcrumb,” as we know how semantics works and as we’re likely to use only one trail.
As I said on said W3C thread, a
div would not be great, but acceptable. But that still leaves two important questions:
1. Why No Lists?
Some lists are clearly not suitable for breadcrumbs, like
menu, or, if you want,
dir, so the list question typically refers to
Unordered lists don’t seem appropriate because breadcrumbs are not an unordered list of related items. They are a somewhat ordered hierarchical list of unrelated items. That leads us straight to ordered lists:
Ordered lists don’t seem appropriate because breadcrumbs don’t represent an order in the sense of first this, then that, then something else. They are a somewhat ordered hierarchical list of unrelated items. That suggests:
Nested lists, which don’t seem appropriate because they’re too much code for the job. (They are, as Reinier Kaper put it, “terribly cumbersome,” and indeed, as I put it, like using “lists for sentences, as sentences are lists of words.”) This is the direct result of what I mentioned before, there just is no dedicated element for breadcrumbs.
I realize that lists still exercise some pull. Breadcrumbs seem to have something “list-y.” My point here is that that’s not enough. It would require one of the HTML editors, like Ian, to rewire my head here.
2. What About HTML 5?
That’s an important and nowadays obvious question. And with the
nav element we find an interesting answer:
navelement represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
Evidently, breadcrumbs link to other pages, and they also represent navigation links. That just doesn’t make them lists, so
nav would work like
div in the markup I suggested in the beginning:
Putting everything together, the simplest adequate markup for breadcrumbs seems to be
<nav id=breadcrumb><a>Item 1</a> → Item 2</nav>
or, in anything HTML that’s not HTML 5,
<div id=breadcrumb><a>Item 1</a> → Item 2</div>
If the ID (or class in case of several occurrences) is actually needed or wanted, that is.
Case solved? Let’s find the holes.
* “>” is a poor delimiter for functional and typographical reasons. “→” is one of the nicer alternatives. It can be argued that breadcrumb delimiters are content and should be part of the document, not of the style sheet. That’s the case I’m building in the examples.
† So simple that I’ve sometimes just used a
p element without any ID or class—like currently on this site.
I’m Jens Oliver Meiert, and I’m a web developer (engineering manager) and author. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have questions or suggestions about what I write, please leave a comment (if available) or a message.
“in anything HTML that’s not HTML 5” - Could you explain what this means?
Breadcrumb are a textual representation of a tree structure. By definition, we lose some informations (siblings, deepness, etc.).
HTML5 is still a poor semantic language.
Should it be more semantic? For what purpose?
What matters is if the user is capable of making a mind-map of that tree.
On October 4, 2013, 9:46 CEST, at said:
Seems like a bad solution for no problem at all. Since “somewhat ordered” means “ordered”, lets keep it written as an ol and wrap it in a nav. And since there are not that many breadcrumbs on a given page the appropriateness of nested lists obviously depends on the laziness of the coder, not on traffic issues.
I think using
olelements would be a nice solution, for example:
<nav class="breadcrumb"> <ol> <li>Item 1</li> <li>Item 2</li> </ol> </nav>
I my opinion nested ordered lists are the best solution representing a breadcrumb so far. It’s a bad argument that they’re too much code.
On October 4, 2013, 16:31 CEST, David said:
Why not use a custom element? Why not register a
<breadcrumb>element? Is that not a valid approach that also meets semantic needs?
I still prefer lists.
Not nested lists though. A breadcrumb represents a path through a tree, not the tree itself. The consecutive items make it clear we’re going step by step down the tree structure, so the path is just one-dimensional.
When you don’t want lists, then at least use block elements to differentiate between element. With inline elements a breadcrumb becomes a single “sentence” which makes no sense at all. Each link is a separate entity, not part of an inline expression.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. Available at Amazon, Google Play Books, and Leanpub.
Looking for a way to comment? Comments have been disabled, unfortunately.