breadcrumbs-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(include self in links in process section, todo, include JSON output of examples)
(→‎h-breadcrumb: add subsections, FAQ for the question JonathanNeal asked, live example)
Line 18: Line 18:
profile/itemtype: <nowiki>http://microformats.org/profile/h-breadcrumb</nowiki>
profile/itemtype: <nowiki>http://microformats.org/profile/h-breadcrumb</nowiki>


==== properties ====
properties:
properties:
* '''<code>p-name</code>'''
* '''<code>p-name</code>'''
* '''<code>u-url</code>'''
* '''<code>u-url</code>'''


==== example ====
Use <code>class="h-breadcrumb"</code> on each breadcrumb hyperlink. E.g. here's a breadcrumb example from [http://support.google.com/webmasters/bin/answer.py?hl=en&answer=185417 Google's breadcrumb documentation] about a page for a particular dress (all breadcrumbs indicate ancestor pages)
Use <code>class="h-breadcrumb"</code> on each breadcrumb hyperlink. E.g. here's a breadcrumb example from [http://support.google.com/webmasters/bin/answer.py?hl=en&answer=185417 Google's breadcrumb documentation] about a page for a particular dress (all breadcrumbs indicate ancestor pages)
<source lang=html4strict>
<source lang=html4strict>
Line 36: Line 38:
<a class="h-breadcrumb" href="http://www.example.com/dresses/real/green">Real Green Dresses</a>  
<a class="h-breadcrumb" href="http://www.example.com/dresses/real/green">Real Green Dresses</a>  
</source>
</source>
This might be rendered as: (live example)
<span class="h-breadcrumb">[http://www.example.com/dresses Dresses]</span> › <span class="h-breadcrumb">[http://www.example.com/dresses/real Real Dresses]</span> › <span class="h-breadcrumb">[http://www.example.com/dresses/real/green Real Green Dresses]</span>


Compared to existing alternatives ([http://www.bing.com/webmaster/help/markup-breadcrumbs-72419f3f Bing], [http://support.google.com/webmasters/bin/answer.py?hl=en&answer=185417 Google]), the <code>h-breadcrumb</code> microformats markup is much simpler.
Compared to existing alternatives ([http://www.bing.com/webmaster/help/markup-breadcrumbs-72419f3f Bing], [http://support.google.com/webmasters/bin/answer.py?hl=en&answer=185417 Google]), the <code>h-breadcrumb</code> microformats markup is much simpler.


The simpler microformats markup is possible since <code>p-name</code> and <code>u-url</code> properties are two of the implied [[microformats2]] properties and there is no need to explicitly specify them.
The simpler microformats markup is possible since <code>p-name</code> and <code>u-url</code> 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.
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.


Line 46: Line 53:
* TODO: add JSON output as produced by a conformant [[microformats2]] processor.
* TODO: add JSON output as produced by a conformant [[microformats2]] processor.


 
==== 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 [[microformats2-parsing|parsed]] into a children collection in their parent microformat, we can use that mechanism for multiple breadcrumb paths on a 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 [[microformats2-parsing|parsed]] into a children collection in their parent microformat, we can use that mechanism for multiple breadcrumb paths on a page.


Line 73: Line 80:


In this case we:
In this case we:
* have to use an explicit <code>p-name</code> properties to distinguish the name of the breadcrumbs that contain other breadcrumbs
* have to use explicit <code>p-name</code> properties to distinguish the name of the breadcrumbs that contain other breadcrumbs
* can still rely upon implied <code>u-url</code>, since there is only one hyperlink that is an direct child of each breadcrumb
* can still rely upon implied <code>u-url</code>, since there is only one hyperlink that is a direct child of each breadcrumb
Thus the markup is still incredibly simpler than existing alternatives which require much more explicit markup.
Thus the markup is still much simpler than existing alternatives which require much more explicit markup.


JSON output:
JSON output:
* TODO: add JSON output as produced by a conformant [[microformats2]] processor.
* TODO: add JSON output as produced by a conformant [[microformats2]] processor.


==== FAQ ====
<div class="discussion">
* Why do you nest the breadcrumbs?
** You nest the breadcrumbs only when there are multiple breadcrumb paths on a page. So processors can distinguish each path instead of assuming all breadcrumbs on the page are part of one path.


== see also ==
== see also ==

Revision as of 00:16, 7 March 2013

<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

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://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>

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:

  • TODO: add JSON output as produced by a conformant microformats2 processor.

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:

  • TODO: add JSON output as produced by a conformant microformats2 processor.

FAQ

  • Why do you nest the breadcrumbs?
    • You nest the breadcrumbs only when there are multiple breadcrumb paths on a page. So processors can distinguish each path instead of assuming all breadcrumbs on the page are part of one path.

see also