breadcrumbs-brainstorming
<entry-title>breadcrumbs brainstorming</entry-title>
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:
p-nameu-url
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://www.example.com/dresses">Dresses</a> ›
<a href="http://www.example.com/dresses/real">Real Dresses</a> ›
<a href="http://www.example.com/dresses/real/green">Real Green Dresses</a>
With h-breadcrumb:
<a class="h-breadcrumb" href="http://www.example.com/dresses">Dresses</a> ›
<a class="h-breadcrumb" href="http://www.example.com/dresses/real">Real Dresses</a> ›
<a class="h-breadcrumb" href="http://www.example.com/dresses/real/green">Real Green Dresses</a>
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.
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.
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 an explicit
p-nameproperties 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 an direct child of each breadcrumb
Thus the markup is still incredibly simpler than existing alternatives which require much more explicit markup.