breadcrumbs brainstorming

This page is for documenting proposals for a breadcrumbs microformat per the microformats process:

analysis of existing formats

Existing breadcrumbs-formats have a high degree of overlap in terms of what properties they use:

name/title
url
child (all but schema)

And they all agree on calling breadcrumbs, "breadcrumbs", and the singular for the individual breadcrumbs. This should be taken into consideration for any proposed breadcrumbs format.

proposals

h-breadcrumb

root class name: h-breadcrumb
profile/itemtype: http://microformats.org/profile/h-breadcrumb

properties

properties:

p-name
u-url

example

Use class="h-breadcrumb" on each breadcrumb hyperlink. E.g. here's a breadcrumb example from Google's breadcrumb documentation about a page for a particular dress (all breadcrumbs indicate ancestor pages)

<a href="http://example.com/dresses">Dresses</a> › 
<a href="http://example.com/dresses/real">Real Dresses</a> › 
<a href="http://example.com/dresses/real/green">Real Green Dresses</a>

With h-breadcrumb:

<a class="h-breadcrumb" href="http://example.com/dresses">Dresses</a> › 
<a class="h-breadcrumb" href="http://example.com/dresses/real">Real Dresses</a> › 
<a class="h-breadcrumb" href="http://example.com/dresses/real/green">Real Green Dresses</a>

This might be rendered as: (live example)

Dresses › Real Dresses › Real Green Dresses

Compared to existing alternatives (Bing, Google), the h-breadcrumb microformats markup is much simpler.

The simpler microformats markup is possible since p-name and u-url properties are two of the implied microformats2 properties and there is no need to explicitly specify them in common cases (e.g. when a single hyperlink element provides all the information).

consuming processors

Consuming processors simply treat the set of breadcrumbs in document order as the set of breadcrumb ancestors, first being the top, and last breadcrumb being the immediate parent of the current page.

JSON output as produced by a conformant microformats2 processor parsing the simple example above:

{
  "items": [
    { "type": ["h-breadcrumb"],
      "properties": {
        "name": ["Dresses"],
        "url": ["http:\/\/example.com\/dresses"]
      }
    },
    { "type": ["h-breadcrumb"],
      "properties": {
        "name": ["Real Dresses"],
        "url": ["http:\/\/example.com\/dresses\/real"]
      }
    { "type": ["h-breadcrumb"],
      "properties": {
        "name": ["Real Green Dresses"],
        "url": ["http:\/\/example.com\/dresses\/real\/green"]
      }
    }
  ]
}

multiple breadcrumb paths

If a page has multiple breadcrumb paths to the current document, then more explicit markup must be used. Pre-existing formats use an explicit "child" property to do this. However, since nested microformats are automatically parsed into a children collection in their parent microformat, we can use that mechanism for multiple breadcrumb paths on a page.

Example (re-used again from the Google documentation) of multiple breadcrumb paths on a page for a specific Stephen King book:

<div class="h-breadcrumb">
  <a class="p-name" href="http://example.com/books">Books</a> ›
  <div class="h-breadcrumb">
    <a class="p-name" href="http://example.com/books/authors">Authors</a> ›
    <div class="h-breadcrumb">
      <a href="http://example.com/books/authors/stephenking">Stephen King</a>
    </div>
  </div>
</div>

<div class="h-breadcrumb">
  <a class="p-name" href="http://example.com/books">Books</a> ›
  <div class="h-breadcrumb">
    <a class="p-name" href="http://example.com/books/fiction">Fiction</a> ›
    <div class="h-breadcrumb">
      <a href="http://example.com/books/fiction/horror">Horror</a>
    </div>
  </div>
</div>

In this case we:

have to use explicit p-name properties to distinguish the name of the breadcrumbs that contain other breadcrumbs
can still rely upon implied u-url, since there is only one hyperlink that is a direct child of each breadcrumb

Thus the markup is still much simpler than existing alternatives which require much more explicit markup.

JSON output as produced by a conformant microformats2 processor parsing this example:

{
  "items": [
    { "type": ["h-breadcrumb"],
      "properties": {
        "name": ["Books"],
        "url": ["http:\/\/example.com\/books"]
      },
      "children": [
        { "type": ["h-breadcrumb"],
          "properties": {
            "name": ["Authors"],
            "url": ["http:\/\/example.com\/books\/authors"]
          },
          "children": [
            { "type": ["h-breadcrumb"],
              "properties": {
                "name": ["Stephen King"],
                "url": ["http:\/\/example.com\/books\/authors\/stephenking"]
              }
            }
          ]
        }
      ]
    },
    { "type": ["h-breadcrumb"],
      "properties": {
        "name": ["Books"],
        "url": ["http:\/\/example.com\/books"]
      },
      "children": [
        { "type": ["h-breadcrumb"],
          "properties": {
            "name": ["Fiction"],
            "url": ["http:\/\/example.com\/books\/fiction"]
          },
          "children": [
            { "type": ["h-breadcrumb"],
              "properties": {
                "name": ["Horror"],
                "url": ["http:\/\/example.com\/books\/fiction\/horror"]
              }
            }
          ]
        }
      ]
    }
  ]
}

FAQ

Why do you nest the breadcrumbs?
- You nest the breadcrumbs only when there are multiple breadcrumb paths on a page. Nesting is needed for processors to distinguish the paths instead of assuming all breadcrumbs on the page are part of one path.