Microformats Wiki - User contributions [en]

testimonials

2022-12-07T00:28:40Z

Btrem: /* Asiabizsetup */ Spelling correction

{{DISPLAYTITLE: Testimonals }}

== [https://twitter.com/jgmac1106/status/1020254211043463168 Greg McVerry] ==
… JSON-LD and <nowiki>http://schema.org</nowiki> . Looked impossible to implement. Found [[mf2]] said, “I can do that.”

== [https://indiewebcamp.com/irc/2014-06-21/line/1403415993000 Kartik Prabhu] ==
I have found that microformats are easier to write than [[RDF]] or [[microdata]].[https://indiewebcamp.com/irc/2014-06-21/line/1403415993000]

== [http://www.asiabizsetup.net Asiabizsetup] ==
I love how microformats do its job. It helps my site be more organized and structure. Without proper structure, it's kind of hard to do things. I hope that adding microformats to the site will also make it easier for reader as it will be more user friendly. Apart from that, I would like to Thanks a team of microformats.org that make things easy for all of us to use. If anyone who don't know or not good in html, There is a tools for us to use and make good code. I'm appreciated for what you do here and please don't stop, let's keep it rolling.

These are stories from the [http://microformats.org/discuss/mail/microformats-discuss microformats-discuss mailing list], where users characterize why exactly they find microformats so useful and compelling.

== [http://gravit.as Scott Rozic] ==
I'm jazzed about microformats, and right now i just made an ultra-micro posting system with it, I've created a new blog that's deeply microformatted, and will be rolling microformats into 5 or so new applications by the end of this year! Still in the experimentation phase but lots can be done here to standardize the cross-web, cross-app experience for users and make life easier for app and site builders.

== [http://www.lizcoworldwide.com/wordpress/index.php?p=92 Liz Dunn] ==
I wrote a little essay on my personal blog about why I like, nay, LOVE, microformats. The goal of this essay was to get my friends, who aren't super extra into web formats, excited about the possibilities of microformats. I'm not sure it worked, since one friend commented that she didn't think she was the audience for my blog anymore. But I'm not going to stop writing about microformats!

== [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001253.html Kevin Lawver] ==

My personal interest in microformats stems from my general laziness and love of conformity. I don't want to have to think about how to mark something up all the time. I think Microformats can go a long way towards standardizing how we mark up particular pieces of data... I work at a company that has a huge collection of developers spread all over the world. If I can tell all of them, "Hey, you should mark a review or search result or list of blog posts this way, and heres' the documentation," they'll be more likely to do that, and we'll have an easier time maintaining and "discovering" that content.

== [http://jamierumbelow.net/ Jamie Rumbelow] ==
I don't think anything this exciting, productive or helpful has hit the web in a very long time. The ever-expanding library of semantic yet resourceful Microformats are constantly amazing me with their intuition, and ability to get the job done then get out of my way.

== [http://microformats.org/discuss/mail/microformats-discuss/2005-October/001181.html Ernest Prabhakar] ==

=== Organization web page ===

I'm responsible for the website for an informal group at work. The
HTML I inherited was a horrible mess, and painful to maintain. I
realized that it was pretty much just a list of events, people, and
resources. So, just to avoid having to think about HTML design, I
turned the whole thing into a bunch of XOXO, hCards, and hEvents.
Then, in order to make it look the way I wanted, I just added (or
often, stole:-) appropriate style declarations.

Could I have done this without microformats? Actually, no. ''You''
might, but '''I''' couldn't. Microformat was the crutch to help me think
intelligently about CSS. As a bonus, I can now use all these funky
tools to extract vCards -- and show the entire site as a
presentation. Cool!

=== Custom application format ===

One of my side projects is working on a program to display lyrics for
sing-a-longs (i.e., church worship services). I was experimenting
with a bunch of different XML schemas, but a) I wasn't sure I had it
right, and b) there was no way I could imagine getting a lot of
people to adopt it.

Then I discovered [http://www.meyerweb.com/eric/tools/s5 S5].
I suddenly realized that XOXO was the perfect format for encoding lyrics (stanzas, lines, etc.).
It is so obviously *right* that it is trivial to evangelize, rather
than arguing over every last tag. It is flexible, so people can add
their own metadata if needed, and socialize them informally rather
than having to push them through a central standard (which I'd have
to maintain, ugh). It is also non-intimidating, so people who know
HTML but not XML (believe me, there's a lot of them) are comfortable
adopting it.

Not bad. But wait, there's more! This also means:
# There's a trivial way to view every file (browser), even without my app
# Design can be done using CSS, meanings trivial to customize -- I don't need to provide a tool
# I can reuse the existing HTML viewing tools on my platform

At this point, I literally cannot imagine tackling any web site or
application format problem withOUT leveraging existing
microformats. It is the shortest route to success for the kinds of
things *I* care about. Where getting an 80% solution out - now- is
the most important thing. If you slice the 80/20 correctly, it is
actually only the top 5% of customers who ever actually run into the
tough edge cases. The long tail rarely cares -- certainly not enough
to pay the added cost.

Its kinda like optimizing source code. Its better to write it first
then optimize the hotspots, than try to pre-optimized what you *think*
the problems will be.

== [https://jamesg.blog James Gallagher] ==

Microformats are easy to use. Unlike other methods of markup, they do not require creating a new JavaScript object or a separate document in which data is placed. My microformats are in the HTML code that browsers render. I can easily read my HTML code and see the relationship between my code and the data I want to mark up. Microformats and are extensively supported with services that I would like to use, from [https://indieauth.net IndieAuth] to [https://brid.gy brid.gy]. As a bonus, microformats makes my content easier for Google search to interpret.

why-using-existing-matters

2022-12-05T20:28:17Z

Btrem: Removes self-reference.

<h1>Why using existing microformats matters</h1>

When many folks first hear of [[microformats]], they are quite inspired by the possibilities and potential that microformats present.

Nearly everyone seems to have a problem in the back of their minds, or specific to their application, site, or service which could benefit from a microformat to represent the information.

Thus immediately there is a desire to jump to creating a new such microformat, perhaps seduced by the ease of use of existing microformats. It's easy to misconclude from the simplicity of existing microformats that it is also simple to create microformats. Ironically, the opposite is true. As with many things, it's actually quite challenging and difficult to make simple, easy to use things. This is a known axiom in [[user-interface]] design circles. It's no different with formats. See [[why-are-content-standards-hard]] for some general thoughts on why good and simple formats are actually quite difficult to create.

The motivation to create a new microformat might lead some here, to the microformats [[Main_Page|wiki]] or perhaps even the [[process]] page before proceeding.

Thus the process page encourages the reader to:

* Add <em>existing</em> microformats to your sites like [[hcard|hCard]] for your contact info etc., [[hcalendar|hCalendar]] for your events, [[hatom|hAtom]] for your episodic content (e.g. blogs). See [[get-started]] for more specific examples of adding microformats to your sites.
* This will help familiarize you with how [[POSH]] and [[microformats]] currently work. Such "real world" experience will greatly help you with the development a new microformat.

Success in developing microformats requires both creation but more importantly adoption; any effort to create new schema depends upon your prior support for and implementation of existing formats.

One rhetorical question to consider about using existing microformats vs. creating a new one: ''How can you have a chance of convincing others to use a ''new'' microformat (that you would develop) on their sites, if you can't convince yourself to use ''existing'' microformats on your sites?''

Or put in a more positive light: ''If you adopt microformats and develop your own with the microformats process, you have a greater chance of being successful, whereas, if you develop your own format without implementing prior formats, you are more likely to fail.''

Failures may even take strange forms that are hard to recognize until it is too late. I.e. if you don't first familiarize yourself with existing microformats (most of all, by using them in actual production sites), you're likely to make lots of mistakes while developing your own format. It's likely to take a lot longer for you to develop your microformat. It's likely your microformat will be needlessly complicated. And because you won't be familiar with both whole existing microformats and their vocabularies, you will more than likely re-invent chunks of microformats and terms, rather than re-use from existing microformats.

== see also ==
* [[get-started]]
* [[why-are-content-standards-hard]]
* [[principles]]
* [[process]]

menu-examples

2022-12-05T19:21:25Z

Btrem: /* Break Restaurant */ Grammar correction

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] has a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The [https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus in the United States. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

==== Toast Tab ====
Toast Tab is a restaurant <abbr title="point of sales>P.O.S.</abbr> system. It offers an online ordering for pickup service that publishes the restaurant's menu. Since Toast Tab is publishing from the restaurant's POS system -- i.e., the same system that employees use to enter an order for patrons in the restaurant -- their menus are likely to be accurate.

=== menu duplication ===
Many restaurants publish their menu on more than one site, usually because they subscribe to a third party service which copies their menu for the convenience of that service's customers. At minimum, this entails reentering data. Often, the menus are out of sync.

==== The Sitting Room ====
The Sitting Room is a wine bar in Seattle, Washington, United States.
* [https://www.the-sitting-room.com/food restaurant website menu]
* [https://www.yelp.com/biz_photos/the-sitting-room-seattle?select=dRxYnz9hzLQ4o-VZ1yTPSg photo of menu on Yelp]
* [https://www.toasttab.com/thesittingroom/v3 Toast Tab menu]
* [https://www.opentable.com/restaurant/profile/206647 Open Table menu]
* [https://www.tripadvisor.com/Restaurant_Review-g60878-d432572-Reviews-The_Sitting_Room-Seattle_Washington.html Trip Advisor menu]
These five urls appear to contain three different menus:
# Trip Advisor and Open Table
# Sitting Room (i.e. their own website) and Toast Tab
# Yelp

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

svg

2022-12-01T15:55:38Z

Btrem: /* Examples */ Removes unneeded rect element

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Examples ==

Here are a couple of examples.

* a simple [[h-card]] using [[microformats2-implied-properties | implied properties]]:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

Parsed JSON:

<syntaxhighlight lang="json">
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Example Co."
]
}
}
],
"rels": {},
"rel-urls": {}
}
}
</syntaxhighlight>

* a slightly more complex example of an [[h-card]] with several specified properties and an embedded [[h-adr]]:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 300 300" height="300" width="300">
<circle cx="100" cy="100" r="100" fill="gold"/>
<text class="p-name" x="25" y="110" font-size="30">
Example Co.
</text>
<g class="p-adr h-adr">
<text class="p-street-address" x="25" y="220" font-size="18">
123 Main St.
</text>
<text x="25" y="240" font-size="18">
<tspan class="p-locality">Pleasantville</tspan>,
<tspan class="p-region">California</tspan>
<tspan class="p-postal-code">90091</tspan>
</text>
</g>
<text class="p-tel" x="25" y="260" font-size="18">
+1-323-555-0100
</text>
</svg>
</syntaxhighlight>

Parsed JSON:

<syntaxhighlight lang="json">
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Example Co."
],
"adr": [
{
"type": [
"h-adr"
],
"properties": {
"street-address": [
"123 Main St."
],
"locality": [
"Pleasantville"
],
"region": [
"California"
],
"postal-code": [
"90091"
]
},
"value": "123 Main St. Pleasantville, California 90091"
}
],
"tel": [
"+1-323-555-0100"
]
}
}
],
"rels": {},
"rel-urls": {}
}
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

svg

2022-12-01T01:12:53Z

Btrem: /* Example */ Adds second example of svg with h-card markup

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Examples ==

Here are a couple of examples.

* a simple [[h-card]] using [[microformats2-implied-properties | implied properties]]:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

Parsed JSON:

<syntaxhighlight lang="json">
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Example Co."
]
}
}
],
"rels": {},
"rel-urls": {}
}
}
</syntaxhighlight>

* a slightly more complex example of an [[h-card]] with several specified properties and an embedded [[h-adr]]:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 300 300" height="300" width="300">
<rect width="100%" height="100%" fill="none" stroke="red" />
<circle cx="100" cy="100" r="100" fill="gold"/>
<text class="p-name" x="25" y="110" font-size="30">
Example Co.
</text>
<g class="p-adr h-adr">
<text class="p-street-address" x="25" y="220" font-size="18">
123 Main St.
</text>
<text x="25" y="240" font-size="18">
<tspan class="p-locality">Pleasantville</tspan>,
<tspan class="p-region">California</tspan>
<tspan class="p-postal-code">90091</tspan>
</text>
</g>
<text class="p-tel" x="25" y="260" font-size="18">
+1-323-555-0100
</text>
</svg>
</syntaxhighlight>

Parsed JSON:

<syntaxhighlight lang="json">
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Example Co."
],
"adr": [
{
"type": [
"h-adr"
],
"properties": {
"street-address": [
"123 Main St."
],
"locality": [
"Pleasantville"
],
"region": [
"California"
],
"postal-code": [
"90091"
]
},
"value": "123 Main St. Pleasantville, California 90091"
}
],
"tel": [
"+1-323-555-0100"
]
}
}
],
"rels": {},
"rel-urls": {}
}
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

svg

2022-12-01T00:29:25Z

Btrem: Adds parsed json resulting from simple example

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Example ==

Here is a simple example:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

Parsed JSON:

<syntaxhighlight lang="json">
{
"items": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Example Co."
]
}
}
],
"rels": {},
"rel-urls": {}
}
}
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

svg

2022-12-01T00:26:05Z

Btrem: Changes simple example to use implied name property of h-card

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Example ==

Here is a simple example:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

svg

2022-11-30T23:59:25Z

Btrem: Fix: corrects syntaxhightlight lang attribute

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Example ==

Here is a simple example:

<syntaxhighlight lang=xml>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text class="p-name" x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

existing-rel-values

2022-11-30T23:54:55Z

Btrem: Fix: replaces deprecated <source> tag with <syntaxhighlight>

{{DISPLAYTITLE: existing rel values }}

This page contains tables of known HTML rel values from specifications, formats, proposals, brainstorms, and non-trivial [[POSH]] usage in the wild. In addition, dropped and rejected values are listed at the end for comprehensiveness.

<span id="usage">usage</span>: see [[rel-faq#How_is_rel_used|how is 'rel' used]]. Regarding <span id="rev">rev</span>, see: [[rel-faq#Should_rev_even_be_used|should 'rev' even be used]].

This page is also the official rel registry ([https://html.spec.whatwg.org/multipage/links.html#other-link-types WHATWG HTML] ([http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types original link]), [http://www.w3.org/TR/html5/links.html#other-link-types W3C HTML5]). Add new and proposed rel values to the following section:
* [[existing-rel-values#HTML5_link_type_extensions|HTML5 link type extension]]

== formats ==
These rel values are defined formats from specifications (HTML 4, microformats) are thus are <strong>recommended for general use</strong>. Alphabetically ordered by value.

Note:
* <strong>Do not</strong> add proposed rel values for HTML5 here, add them to the [[#HTML5_link_type_extensions|HTML5 link type extensions]] table.
* <strong>Do not</strong> add rel values you find in the wild to this table of rel formats, instead add them to the table in the [[existing-rel-values#POSH_usage|POSH section]].
* <strong>Do not</strong> add non-HTML rel values you find to this table of rel formats, instead add them to the table in the [[existing-rel-values#non_HTML_rel_values|non HTML rel values section]].
* <strong>Do not</strong> add rel values from obsolete/superceded proposals or drafts, instead add them to the table in the "dropped" section.

Sources:
* W3C Recommendations:
** [http://www.w3.org/TR/html401/types.html#h-6.12 HTML 4.01 section 6.12 Link types] (HTML4 Link types)
** [http://www.w3.org/TR/grddl/ Gleaning Resource Descriptions from Dialects of Languages] (GRDDL)
* [[microformats]] specifications
** [[xfn]]
** [[rel-license]]
** [[rel-nofollow]]

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description <br />(from the relevant specification where possible)
! Link to defining specification

|-
| [[rel-acquaintance|acquaintance]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [[XFN]]

|-
| [[rel-alternate|alternate]]
| external resource
| external relation
| Designates substitute versions for the document in which the link occurs. When used together with the <code>lang</code> attribute, it implies a translated version of the document. When used together with the <code>media</code> attribute, it implies a version designed for a different medium (or media).
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-appendix|appendix]]
| allowed
| allowed
| Refers to a document serving as an appendix in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-bookmark|bookmark]]
| not allowed
| allowed
| Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The <code>title</code> attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-chapter|chapter]]
| allowed
| allowed
| Refers to a document serving as a chapter in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-child|child]]
| external relation
| external relation
| The referenced person is a child of the person represented by the current document. It may also indicate that the target document is a hierarchical child, or subdocument, of the current document.
| [[XFN]], [https://www.w3.org/TR/relations.html HTML 4.0 Specification]

|-
| [[rel-colleague|colleague]]
| not allowed
| external relation
| the referenced person is a colleague of the person represented by the current document
| [[XFN]]

|-
| [[rel-contact|contact]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [[XFN]]

|-
| [[rel-contents|contents]]
| allowed
| allowed
| Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from "Table of Contents").
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-copyright|copyright]]
| allowed
| allowed
| Refers to a copyright statement for the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-co-resident|co-resident]]
| not allowed
| external relation
| the referenced person lives in the same residence as the person represented by the current document
| [[XFN]]

|-
| [[rel-co-worker|co-worker]]
| not allowed
| external relation
| the referenced person is a co-worker of the person represented by the current document
| [[XFN]]

|-
| [[rel-crush|crush]]
| not allowed
| external relation
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [[XFN]]

|-
| [[rel-date|date]]
| not allowed
| external relation
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [[XFN]]

|-
| [[rel-friend|friend]]
| not allowed
| external relation
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [[XFN]]

|-
| [[rel-glossary|glossary]]
| allowed
| allowed
| Refers to a document providing a list of terms and their definitions that pertain to the current document.||[http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-help|help]]
| allowed
| allowed
| Refers to a document offering help (more information, links to other sources information, etc.)
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-its-rules|its-rules]]
| allowed
| not allowed
| Refers to a document with external ITS rules.
| [http://www.w3.org/TR/its20/#selection-global-html5 Internationalization Tag Set (ITS) Version 2.0]

|-
| [[rel-kin|kin]]
| not allowed
| external relation
| the referenced person is part of the extended family of the person represented by the current document
| [[XFN]]

|-
| [[rel-license|license]]
| allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is a license for the current page.
| [[rel-license]]

|-
| [[rel-me|me]]
| external relation
| external relation
| the referenced document represents the same person as does the current document
| [[XFN]]

|-
| [[rel-met|met]]
| not allowed
| external relation
| this person has met the referenced person
| [[XFN]]

|-
| [[rel-muse|muse]]
| not allowed
| external relation
| the referenced person inspires the person represented by the current document
| [[XFN]]

|-
| [[rel-neighbor|neighbor]]
| not allowed
| external relation
| the referenced person lives nearby the person represented by the current document
| [[XFN]]

|-
| [[rel-next|next]]
| external relation
| external relation
| Refers to the next document in a linear sequence of documents. User agents may choose to preload the "next" document, to reduce the perceived load time.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-nofollow|nofollow]]
| not allowed
| external relation
| indicates that the destination of that hyperlink {{should-not}} be afforded any additional weight or ranking by user agents which perform link analysis upon web pages (e.g. search engines).
| [[rel-nofollow]]

|-
| [[rel-parent|parent]]
| external relation
| external relation
| The referenced person is a parent of the person represented by the current document. It may also indicate that the target document is the hierarchical parent, or container, of the current document.
| [[XFN]], [https://www.w3.org/TR/relations.html HTML 4.0 Specification]

|-
| [[rel-prev|prev]]
| external relation
| external relation
| Refers to the previous document in an ordered series of documents. Some user agents also support the synonym "Previous".
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-previous|previous]]
| external relation
| external relation
| Synonym of <code>prev</code>
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-section|section]]
| allowed
| allowed
| Refers to a document serving as a section in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sibling|sibling]]
| not allowed
| external relation
| the referenced person is a sibling of the person represented by the current document
| [[XFN]]

|-
| [[rel-spouse|spouse]]
| not allowed
| external relation
| the referenced person is a spouse of the person represented by the current document
| [[XFN]]

|-
| [[rel-start|start]]
| allowed
| allowed
| Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-stylesheet|stylesheet]]
| external resource
| not allowed
| a style sheet for the current document<br /> used with the invisible <link href> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <a href> are strongly preferred. Unfortunately the use of stylesheet in user visible content like <a href> appears to be strictly theoretical.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-subsection|subsection]]
| allowed
| allowed
| Refers to a document serving as a subsection in a collection of documents.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-sweetheart|sweetheart]]
| not allowed
| external relation
| this person considers the referenced person to be their sweetheart
| [[XFN]]

|-
| [[rel-tag|tag]]
| not allowed
| allowed
| …indicates that the <nowiki>[referenced document]</nowiki> is an author-designated "tag" (or keyword/subject) for the current page.
| [[rel-tag]]

|-
| [[rel-toc|toc]]
| allowed
| allowed
| Synonym of <code>contents</code> (from "Table Of Contents")
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4 Link types]

|-
| [[rel-transformation|transformation]]
| allowed
| allowed
| Relates a source document to a transformation, usually represented in XSLT, that relates the source document syntax to the RDF graph syntax. Used in [[grddl|GRDDL]]
| [http://www.w3.org/TR/grddl/#transformation GRDDL]

|}

=== notes ===
*<code>rel="alternate"</code> can take further meaning from additional attributes, such as
** <code>rel="alternate" lang="fr"</code> (French language version of this page)
** <code>rel="alternate" media="print"</code> (printable version of this page)
** <code>rel="alternate" media="handheld"</code> (version of the page intended or better for handheld/portable devices like PDAs, cell phones, etc.)

*Synonyms such as "previous", "toc" are not as widely supported as the main term.

== proposals ==
A few rel values have been developed as drafts as a result of going through most of the microformats [[process]], and are thus listed here for your serious consideration. You <strong>may use these values</strong>, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

{| border="1"
|+
! rel value !! summary !! proposed in !! external spec (if any)
|-
| [[rel-pronunciation|pronunciation]] || …indicates that the destination of the 'link' element is a document providing a pronunciation lexicon for speech-synthesis purposes. || [[rel-pronunciation]]
|-
| [[rel-directory|directory]] || …indicates that the destination of the hyperlink is a directory listing containing an entry for the current page. || [[rel-directory]]
|-
| [[rel-enclosure|enclosure]] || …indicates that the destination of that hyperlink is intended to be downloaded and cached. || [[rel-enclosure]] || [http://www.apps.ietf.org/rfc/rfc4287.html RFC4287]
|-
| [[rel-home|home]] || …indicates that the <nowiki>[referenced document]</nowiki> is the homepage of the site in which the current page appears. || [[rel-home]]
|-
| [[rel-payment|payment]] || …indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page|| [[rel-payment]]
|-
| vcs-* || …indicates that the destination of the hyperlink is the location of a Version Control System repository related to that page.|| || [https://joeyh.name/rfc/rel-vcs/ rel=vcs-*]
|}

== HTML5 link type extensions ==

The following values are registered as link type extensions per the [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types requirements in the WHATWG HTML spec] and the [http://www.w3.org/TR/html5/links.html#other-link-types requirements in the W3C HTML5 spec].

Before you register a new value:
* '''Please check the [[#formats|Formats table]] and DO NOT re-register''' rel values that are already there. Please note that the W3C HTML WG has made a [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Decision] to drop <code>index</code>, <code>up</code>, <code>first</code> and <code>last</code> from the HTML5 spec itself.
* '''Please check the [[#dropped|Dropped table]] and DO NOT register''' values that are already there. If you believe a rel value was dropped from another specification without prejudice, please provide link/cite to explicit text/decision stating as such, e.g. the value was merely postponed, or perhaps expected to be spun-out into its own spec from the group developing that specification.

Note that entries in the [[#formats|Formats table]] and entries that are already in HTML5 as built-in keywords are also considered extensions with the "Ratified" status.

Please make sure that registrations added here have all the required data filled in ''including'':
* "Effect on link"
* "Effect on a and area" and
* a link to a spec that documents the keyword ''as an HTML <code>rel</code> keyword''. (A spec that merely defines the file format of the link target but does not define the <code>rel</code> keyword for use in HTML is not the kind of spec that is being required here.)

Entries lacking any of the above required data will likely be removed.

Changes to this registry will not be reflected in validators in real time. But validators will typically get automatically updated with the changes within one week or so

{| border="1"
|+
! Keyword
! Effect on <code>link</code>
! Effect on <code>a</code>, <code>area</code>
! Brief description
! Link to specification
! Synonyms
! Status

|-
| [[rel-about|about]]
| Hyperlink
| Hyperlink
| The resource linked to contains information about the current page.
| [https://www.rfc-editor.org/rfc/rfc6903.html#section-2 RFC6903]
| It might combine with [[rel-me]] or [[rel-author]] in links to an "about" section focused on an author
| proposed

|-
| [[rel-amphtml|amphtml]]
| Hyperlink
| Hyperlink
| Specify an alternate version of the document written in AMP HTML
| [https://github.com/ampproject/amphtml AMP HTML documentation]
| could be combined with rel=alternate
| proposed

|-
| [[rel-apple-touch-icon|apple-touch-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-icon-precomposed|apple-touch-icon-precomposed]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Web Clip”, or “touch icon”, for mobile devices (not limited to Apple devices).
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| probably redundant with rel=icon
| proposed

|-
| [[rel-apple-touch-startup-image|apple-touch-startup-image]]
| External Resource
| Not allowed
| Specify a splashscreen for Web apps on iOS Safari
| [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html Apple's Safari Web Content Guide]
| maybe redundant with rel=icon with the sizes attribute?
| proposed

|-
| [[rel-archived|archived]]
| External Resource
| Hyperlink Annotation
| The target resource is archived and kept largely or solely for historical purposes.
| [https://sitemorse.com/rel-archived/ rel="archived" description]
|
| proposed

|-
| [[rel-attachment|attachment]]
| Hyperlink
| Hyperlink
| The resource linked to is "attached" to this document, similar to email attachments. Used in WordPress.
| No formal specification
|
| proposed

|-
| [[rel-authorization_endpoint|authorization_endpoint]]
| External Resource
| Not allowed
| Specify a hosted authorization server
| [https://www.w3.org/TR/indieauth/ IndieAuth spec]
|
| proposed

|-
| [[rel-canonical|canonical]]
| Hyperlink
| Hyperlink
| Specifies the canonical URL for the current document in order to help avoid duplicate content.
| [http://en.wikipedia.org/wiki/Canonical_meta_tag Canonical meta tag] [http://www.Google.com/support/webmasters/bin/answer.py?answer=139066#2 Canonicalization at Google Webmaster Central] [http://www.Bing.com/community/site_blogs/b/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft Webmaster Center] [http://www.YSearchBlog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo! Search Blog]
|
| proposed

|-
| [[rel-category|category]]
| Hyperlink
| Hyperlink
| Refers to a category assigned to the current document or post. Implemented by WordPress for indicating a relation between a blog post and a category.
| [[rel-category]]
|
| proposed

|-
| [[rel-code-repository|code-repository]]
| Hyperlink
| Hyperlink
| indicates a code repository location. For link, it specifically indicates, in the case of server-generated content, the location of source code responsible for the generation of the current page, or, in the case of static files, where copies of the current page are housed). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and [[rel-content-repository|content-repository]] should be used to indicate the location for the storage of content. Otherwise, the code repository can be considered as also including the content. While the repository should contain its own license file, the [[rel-code-license|code-license]] rel-value is proposed as a direct pointer to the license (see also [[rel-content-license|content-license]]).
|
|
| proposed

|-
| [[rel-code-license|code-license]]
| Hyperlink
| Hyperlink
| indicates a license for code (a proposed broader replacement for [[rel-jslicense|jslicense]]). For link, it specifically indicates, in the case of server-generated content, the location of the license for all source code responsible for the generation of the current page, or, in the case of static files, the location of the license for all of these files). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the generator and [[rel-content-license|content-license]] should be used to indication the license for the content. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the static or generator code files should be done with [[rel-code-repository|code-repository]] (and [[rel-content-repository|content-repository]] for any separate content).
|
|
| proposed

|-
| [[rel-component|component]]
| External Resource
| Not allowed
| Specify an HTML document that is treated as a component of this document.
| [https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Web Components]
|
| proposed

|-
| [[rel-chrome-webstore-item|chrome-webstore-item]]
| External Resource
| Not allowed
| Link tag to declare for app and extensions inline installations hosted in the Chrome Web Store.
| [https://developers.google.com/chrome/web-store/docs/inline_installation Using Inline Installation]
|
| proposed

|-
| [[rel-content-repository|content-repository]]
| Hyperlink
| Hyperlink
| indicates a repository housing data content. For link, it specifically indicates, in the case of server-generated content, the location where separately housed data files used to populate the current page are stored (otherwise "code-repository" is sufficient to include content as well as code). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and [[rel-code-repository|code-repository]] should be used to indicate the location for the storage of the generator source files. Otherwise, [[rel-code-repository|code-repository]] can be considered as also including the content instead. While the repository should contain its own license file, the [[rel-content-license|content-license]] rel-value is proposed as a direct pointer to the license (see also [[rel-code-license|code-license]]).
|
|
| proposed

|-
| [[rel-content-license|content-license]]
| Hyperlink
| Hyperlink
| indicates a license for data content. For link, it specifically indicates, in the case of server-generated content, the location of the license for all separately housed data files used to populate the current page are stored, (otherwise "code-license" is sufficient to cover the license of content as well as code)). If the specific data/content built up at the page is stored separately from the generator (e.g., the code for a CMS vs. the specific CMS instance's SQL tables or JSON data files), this only refers to the data/content files and [[rel-code-license|code-license]] should be used to indication the license for the generator source files. Otherwise, code-license can be considered as also covering the license of the content. Pointing to the repository containing the data files should be done with [[rel-content-repository|content-repository]] (and [[rel-code-repository|code-repository]] for the static or generator code files).
|
|
| proposed

|-
| [[rel-dcterms.(property)#conformsTo|DCTERMS.conformsTo]]
| External Resource
| Not allowed
| An established standard to which the described resource conforms. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.conformsTo" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#contributor|DCTERMS.contributor]]
| External Resource
| Not allowed
| An entity responsible for making contributions to the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.contributor" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#creator|DCTERMS.creator]]
| External Resource
| Not allowed
| An entity primarily responsible for making the resource. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.creator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#description|DCTERMS.description]]
| External Resource
| Not allowed
| An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.description" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#hasFormat|DCTERMS.hasFormat]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the pre-existing described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasPart|DCTERMS.hasPart]]
| External Resource
| Not allowed
| A related resource that is included either physically or logically in the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#hasVersion|DCTERMS.hasVersion]]
| External Resource
| Not allowed
| A related resource that is a version, edition, or adaptation of the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isFormatOf|DCTERMS.isFormatOf]]
| External Resource
| Not allowed
| A related resource that is substantially the same as the described resource, but in another format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isPartOf|DCTERMS.isPartOf]]
| External Resource
| Not allowed
| A related resource in which the described resource is physically or logically included. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReferencedBy|DCTERMS.isReferencedBy]]
| External Resource
| Not allowed
| A related resource that references, cites, or otherwise points to the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isReplacedBy|DCTERMS.isReplacedBy]]
| External Resource
| Not allowed
| A related resource that supplants, displaces, or supersedes the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isRequiredBy|DCTERMS.isRequiredBy]]
| External Resource
| Not allowed
| A related resource that requires the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#isVersionOf|DCTERMS.isVersionOf]]
| External Resource
| Not allowed
| A related resource of which the described resource is a version, edition, or adaptation. <br />Changes in version imply substantive changes in content rather than differences in format. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#license|DCTERMS.license]]
| External Resource
| Not allowed
| A legal document giving official permission to do something with the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.license" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#mediator|DCTERMS.mediator]]
| External Resource
| Not allowed
| An entity that mediates access to the resource and for whom the resource is intended or useful. In an educational context, a mediator might be a parent, teacher, teaching assistant, or care-giver. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.mediator" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#publisher|DCTERMS.publisher]]
| External Resource
| Not allowed
| An entity responsible for making the resource available. Examples include a person, an organization, or a service. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.publisher" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#references|DCTERMS.references]]
| External Resource
| Not allowed
| A related resource that is referenced, cited, or otherwise pointed to by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#relation|DCTERMS.relation]]
| External Resource
| Not allowed
| A related resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#replaces|DCTERMS.replaces]]
| External Resource
| Not allowed
| A related resource that is supplanted, displaced, or superseded by the described resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#requires|DCTERMS.requires]]
| External Resource
| Not allowed
| A related resource that is required by the described resource to support its function, delivery, or coherence. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#rightsHolder|DCTERMS.rightsHolder]]
| External Resource
| Not allowed
| A person or organization owning or managing rights over the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
| It may be replaced by the literal value in form of <code><meta name="DCTERMS.rightsHolder" content="..." /></code>
| proposed

|-
| [[rel-dcterms.(property)#source|DCTERMS.source]]
| External Resource
| Not allowed
| A related resource from which the described resource is derived. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-dcterms.(property)#subject|DCTERMS.subject]]
| External Resource
| Not allowed
| The topic of the resource. <br />
Requires Dublin Core namespace declaration: <code>'''<link rel="schema.DCTERMS" href="<nowiki>http://purl.org/dc/terms/</nowiki>" />'''</code>
| [http://dublincore.org/documents/dcmi-terms/ DCMI Metadata Terms]
|
| proposed

|-
| [[rel-disclosure|disclosure]]
| Not allowed
| External Resource
| The 'disclosure' Link Relation Type designates a list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified.
| [http://tools.ietf.org/html/draft-yevstifeyev-disclosure-relation The 'disclosure' Link Relation Type]
|
| proposed

|-
| [[rel-discussion|discussion]]
| Hyperlink
| Hyperlink
| Refers to discussion of the current document or post.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-donation|donation]]
| Hyperlink
| Hyperlink
| Indicates that the destination of the hyperlink provides a way to show or give support (e.g. financial) for the current page on a voluntary basis
| No formal specification
| Closely related to [[rel-payment]]
| proposed

|-
| [[rel-dns-prefetch|dns-prefetch]]
| External Resource
| Not allowed
| Tells the browser to perform dns lookup for host names ahead of use.
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla documentation] [http://dev.chromium.org/developers/design-documents/dns-prefetching Google documentation]
|
| proposed

|-
| [[rel-edit|edit]]
| Hyperlink
| Not allowed
| Tells the browser where the current page can be edited
| [http://universaleditbutton.org/Registered_MIME_type#Alternate_Linking_Scheme Universal Edit Button Alternate Linking Scheme]. Implemented in at least [http://mediawiki.org MediaWiki].
|
| proposed

|-
| [[rel-edituri|EditURI]]
| External Resource
| Not allowed
| A blogging auto discovery value, commonly used by WordPress
| [http://bitworking.org/projects/atom/draft-gregorio-09.html#Edit AtomAPI]
|
| proposed

|-
| [[rel-enclosure|enclosure]]
| External Resource
| External Resource
| Indicates that the referred resource is intended to be downloaded and cached.
| [[rel-enclosure]]
|
| proposed

|-
| [[rel-entry-content|entry-content]]
| Not allowed
| External Resource
| Indicates that the referenced document is an alternative display source for an Internet Explorer Web Slice.
| [http://msdn.microsoft.com/en-us/library/cc304073(VS.85).aspx#_alternative Web Slice format specification 0.9]
|
| proposed

|-
| [[rel-external|external]]
| Not allowed
| Hyperlink
| Indicates that the referenced document is not part of the same site as the current document.
| [[rel-external]]
|
| proposed

|-
| [[rel-first|first]]
| Hyperlink
| Hyperlink
| Indicates that the document is part of a sequence, and that the link is leading to the document that is the first logical document in the sequence.
| [https://www.w3.org/TR/2011/WD-html5-20110113/links.html#link-type-first W3C Working Draft 13 January 2011]
|
| proposed

|-
| [[rel-gbfs|gbfs]]
| External Resource
| Not allowed
| The location of the gbfs auto-discovery file
| [https://github.com/NABSA/gbfs/blob/master/gbfs.md General Bikeshare Feed Specification]
|
| proposed

|-
| [[rel-gtfs-static|gtfs-static]]
| External Resource
| Not allowed
| Indicates the associated GTFS Static file
| [https://developers.google.com/transit/gtfs/reference General Transit Feed Specification Reference]
|
| proposed

|-
| [[rel-gtfs-realtime|gtfs-realtime]]
| External Resource
| Not allowed
| Indicates the associated GTFS-Realtime file
| [https://developers.google.com/transit/gtfs-realtime/reference GTFS-realtime Reference]
|
| proposed

|-
| [[rel-home|home]]
| Hyperlink
| Hyperlink
| Refers to the top level document for the current document. It can be combined with 'alternate' to indicate a feed for the site of the current page.
| [[rel-home]]
| [[rel-root]]
| proposed

|-
| [[rel-hub|hub]]
| Hyperlink
| Hyperlink
| Refers to a hub that enables registration for notification of updates to the current page.
| [http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#discovery PubSubHubbub Spec] [https://www.w3.org/TR/websub/ WebSub spec]
|
| proposed

|-
| [[rel-import|import]]
| External Resource
| Not allowed
| HTML Imports are a way to include and reuse HTML documents in other HTML documents.
| [http://www.w3.org/TR/html-imports HTML Imports]
|
| proposed

|-
| [[rel-in-reply-to|in-reply-to]]
| Hyperlink
| Hyperlink
| Refers to an original post that the current page is a comment on or reply to.
| [[rel-in-reply-to]]
|
| proposed

|-
| [[rel-root|root]]
| Hyperlink
| Hyperlink
| The target document is the root node of the hierarchical tree structure that hosts the current document
| No formal specification
| [[rel-home]]
| proposed

|-
| [[rel-index|index]]
| Hyperlink
| Hyperlink
| Refers to a document providing a list of topics with pointers that pertain to the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| proposed

|-
| [[rel-issues|issues]]
| Hyperlink
| Hyperlink
| Refers to issues regarding the current document or specification.
| [[rel-discussion]]
|
| proposed

|-
| [[rel-jslicense|jslicense]]
| Hyperlink
| Hyperlink
| Refers to a document with JavaScript source code and license information (also called a [http://www.gnu.org/licenses/javascript-labels.html JavaScript License Web Labels] page). We might want choose a keyword for this that is more general -- there are many situations besides JavaScript in which it is desirable or required by license agreements (e.g., GNU GPL) to make an offer of both the source code and a copy of a license when distributing object code versions of a given work.
| [[rel-jslicense]]
|
| proposed

|-
| [[rel-last|last]]
| Hyperlink
| Hyperlink
| Indicates that the document is part of a sequence, and that the link is leading to the document that is the last logical document in the sequence.
| [https://www.w3.org/TR/2011/WD-html5-20110113/links.html#link-type-last W3C Working Draft 13 January 2011]
|
| proposed

|-
| [[rel-lightbox|lightbox]]
| Not allowed
| Img Pop-Up
| Images with this attribute are displayed in a larger way than embedded in a website (or how you specified it) when clicked (e.g. with installed "Lightbox 2"-Plugin). When adding [group] to rel="lightbox" all images get a clickable button for next/prev; insert into <code><a rel="lightbox[group]"><img src="http:example.com/img.jpg"></a></code>
| [http://lokeshdhakar.com/projects/lightbox2/ Lightbox 2] (needs actual specification to be kept in this list, this link is just documentation of one implementation)
|
| proposed

|-
| [[rel-lightvideo|lightvideo]]
| Not allowed
| Video Pop-Up
| Loads the video in a lightbox effect
| [https://www.drupal.org/node/252276 Lightbox2 - How to display video content]
|
| proposed

|-
| [[rel-main|main]]
| Hyperlink
| Hyperlink
| The current page is a subsection or a less important page than the target resource
| No formal specification
| It can be a synonym of [[rel-parent]] when the latter refers to a document and not a person. It differs however from [[rel-home]] and [[rel-root]], as the latter refer only to the topmost resource in the hierarchical tree structure (and in this case they may be combined with [[rel-main|main]]). Note that [[rel-main]] does not necessarily refer to a higher node in a tree structure, as the target resource can simply be a more important sibling node.
| proposed

|-
| [[rel-manifest|manifest]]
| External Resource
| Not allowed
| Imports or links to a manifest
| [http://w3c.github.io/manifest/#linking W3C Manifest for web application]
|
| proposed

|-
| [[rel-mask-icon|mask-icon]]
| External Resource
| Not allowed
| Specify a Webpage Icon for a “Pinned Tabs” on Safari 9.
| probably redundant with rel-icon
|
| proposed

|-
| [[rel-meta|meta]]
| External Resource
| Not allowed
| External metadata about the HTML document
| [http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-rdf-in-HTML W3C's RDF/XML Syntax Specification]
|
| proposed

|-
| [[rel-micropub|micropub]]
| External Resource
| Not allowed
| the micropub endpoint for creating new posts
| [https://www.w3.org/TR/micropub/ Micropub scecification]
|
| proposed

|-
| [[rel-noopener|noopener]]
| Not allowed
| Annotation
| Requires that any browsing context created by following the hyperlink must not have an opener browsing context.
| [https://html.spec.whatwg.org/multipage/semantics.html#link-type-noopener 4.6.6.11 Link type ”noopener"]
|
| proposed

|-
| [[rel-openid.delegate|openid.delegate]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 1.1 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid.server|openid.server]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 1.1 authentication
| [http://openid.net/specs/openid-authentication-1_1.html#anchor4 OpenID Authentication 1.1]
|
| proposed

|-
| [[rel-openid2.local_id|openid2.local_id]]
| External Resource
| Not allowed
| When the page that contains the link is used as an OpenID indentifier, the relying party perform sOpenID 2.0 authentication with the link target as the identifier instead.
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-openid2.provider|openid2.provider]]
| External Resource
| Not allowed
| The OpenID server for the relying party to contact for OpenID 2.0 authentication
| [http://openid.net/specs/openid-authentication-2_0.html#rfc.section.7.3.3 OpenID Authentication 2.0]
|
| proposed

|-
| [[rel-p3pv1|p3pv1]]
| External Resource
| Not allowed
| References a machine-readable privacy policy description in the P3P format
| [http://www.w3.org/TR/P3P/#syntax_link P3P spec]
|
| proposed

|-
| [[rel-pgpkey|pgpkey]]
| External Resource
| Not allowed
| Associates a PGP key with a Web page so that the Web page URL can be used as the commenter's URL in PGP-signed blog comments and the blogging system receiving the comment can fetch the key and verify the signature as belonging to the owner of the URL.
| [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html PGP-Signed Comments]
|
| proposed

|-
| [[rel-pingback|pingback]]
| External Resource
| Not allowed
| gives the address of the pingback server that handles pingbacks to the current document
| [http://www.hixie.ch/specs/pingback/pingback Pingback]
|
| proposed

|-
| [[rel-preconnect|preconnect]]
| External Resource
| Not allowed
| Indicates an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high costs of connection establishment latency.
| [http://www.w3.org/TR/resource-hints/ Resource Hints Working Draft]
|
| proposed

|-
| [[rel-prerender|prerender]]
| External Resource
| External Resource
| Prerenders the Web page targeted by the link including running it scripts.
| [[rel-prerender]]
|
| proposed

|-
| [[rel-profile|profile]]
| External Resource
| Contextual External Resource
| indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof. See also [[xmdp-brainstorming]].
| [http://microformats.org/wiki/rel-profile rel-profile]
|
| proposed

|-
| [[rel-publisher|publisher]]
| External Resource
| External Resource
| Indicates that the referenced document is a metadata profile (e.g., a social-media/real-name profile such as a Google+ profile) for the publisher of the current page, or some portion of the current page.
| [https://support.google.com/plus/answer/1713826?hl=en Google help page]
|
| proposed

|-
| [[rel-radioepg|radioepg]]
| External Resource
| External Resource
| Indicates that the referenced document is a RadioDNS Service Information document (ETSI TS 102 818 s10.2.3) containing information on the radio station that publishes the current page
| [https://radiodns.org/developers/documentation RadioDNS Documentation]
|
| proposed

|-
| [[rel-rendition|rendition]]
| External Resource
| External Resource
| Indicates some example rendering, interpretation, or depiction of the source. User agents may choose to execute, display, or render the target in-place; or navigate to the target.
| [http://www.globalmentor.com/specs/html-rel-rendition/ HTML rel rendition]
|
| proposed

|-
| [[rel-reply-to|reply-to]]
| External Resource
| Hyperlink
| indicates any mailbox(es) (i.e. email addresses) to which responses are to be sent. ''Note: this is distinct from the 'in-reply-to' value which refers to the originating document, not to the address where comments should be sent.
| [http://tools.ietf.org/html/rfc2822 RFC2822] (originally [http://tools.ietf.org/html/rfc822#section-4.4.3 RFC822])
|
| ratified

|-
| [[rel-schema.DCTERMS|schema.DCTERMS]]
| External Resource
| Not allowed
| Maps the prefix "DCTERMS" for use in other Dublin-Core related link relations (such as DCTERMS.creator) and meta keywords
| [http://dublincore.org/documents/dc-html/#sect-4.2 Section 4.2 of "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"]
| see also [https://wiki.whatwg.org/wiki/MetaExtensions "WhatWG MetaExtensions Wiki] for usage examples in meta keywords
| proposed

|-
| [[rel-service|service]]
| External Resource
| Not allowed
| Atom Publishing Protocol editing service autodiscovery.
| [http://wiki.whatwg.org/wiki/ServiceRelExtension Documentation on the WHATWG wiki]
|
| proposed

|-
| [[rel-shortlink|shortlink]]
| External Resource
| Not allowed
| Specifies the preferred shortened URL for the page.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink spec]
|
| proposed

|-
| [[rel-sidebar|sidebar]]
| Hyperlink
| Hyperlink
| Indicates that the referenced document is intended to be shown in a secondary browsing context.
| [[rel-sidebar]]
|
| proposed

|-
| [[rel-sitemap|sitemap]]
| External Resource
| Not allowed
| Provides a link to an XML document describing the layout of the site.
| [[rel-sitemap]]
|
| proposed

|-
| [[rel-subresource|subresource]]
| External Resource
| Not allowed
| An external resource intended for use within the current page.
| [http://www.chromium.org/spdy/link-headers-and-server-hint/link-rel-subresource Chromium documentation]
|
| proposed

|-
| [[rel-sword|sword]]
| Hyperlink
| Not allowed
| SWORD is a lightweight protocol for remotely depositing content into repositories. .[http://swordapp.org/ The SWORD project]
| [[rel-sword]]
|
| proposed

|-
| [[rel-syndication|syndication]]
| Hyperlink
| Hyperlink
| Refers to a page which is a syndicated copy of the current page.
| [[rel-syndication]]
|
| proposed

|-
| [[rel-timesheet|timesheet]]
| External Resource
| Not allowed
| Applies a timesheet to the document.
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet non-normative section in the Timesheet spec]
|
| proposed

|-
| [[rel-token_endpoint|token_endpoint]]
| External Resource
| Not allowed
| Specify an HTTP endpoint that Micropub clients can use to obtain an access token given an authorization code
| [https://www.w3.org/TR/indieauth/ IndieAuth spec]
|
| proposed

|-
| [[rel-webmention|webmention]]
| External Resource
| Hyperlink
| gives the address of the webmention endpoint that handles webmentions to the current document
| [https://www.w3.org/TR/webmention/ Webmention specification]
|
| proposed

|-
| [[rel-widget|widget]]
| External Resource
| External Resource
| Autodiscovery for W3C widgets
| [http://dev.w3.org/2006/waf/widgets/Overview.html#linking-to-a-widget-package-from-a-html- non-normative section in the Widget packaging spec]
|
| proposed

|-
| [[rel-wlwmanifest|wlwmanifest]]
| External Resource
| Not allowed
| Windows Live Writer manifest autodiscovery
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx documentation on MSDN]
|
| proposed

|-
| [[rel-image_src|image_src]]
| External Resource
| Not allowed
| Specify a Webpage Icon for use by Facebook, Yahoo, Digg, etc.
| Unknown, but see for instance [http://www.niallkennedy.com/blog/2009/03/enhanced-social-share.html this]
| probably redundant with rel=icon
| proposed

|-
| [[rel-cmis-acl|http://docs.oasis-open.org/ns/cmis/link/200908/acl]]
| External Resource
| External Resource
| Identifies the resource containing a CMIS ACL document for the link context
| [http://docs.oasis-open.org/cmis/CMIS/v1.0/cs01/cmis-spec-v1.0.html#_Toc243905525 CMIS 1.0, Section 3.4.3.4]
|
| proposed

|-
| [[rel-stylesheet/less|stylesheet/less]]
| External Resource
| Not allowed
| Less CSS framework stylesheets.
| [http://lesscss.org/#-client-side-usage Less CSS usage]
|
| proposed

|-
| [[rel-yandex-tableau-widget|yandex-tableau-widget]]
| External Resource
| Not allowed
| Lets webmasters configure the appearance of their own site widgets in Yandex.Browser
| [https://api.yandex.com/tableau/ Yandex's Tableau API]
|
| proposed

|}

== brainstorming ==
Several rel values are being brainstormed as potential microformats and are thus listed here. If you find you have a use for such semantics in real world examples, <strong>consider trying out</strong> these values and provide feedback on the respective brainstorming page(s) with your results and experiences.

You may list new proposed rel values here, and even better if you can list and link to POSH uses in the wild.

{| border="1"
|+
! rel value !! summary !! brainstormed in and usage in the wild

|-
| [[rel-accessibility|accessibility]] || indicate[s] that the destination of that hyperlink contains accessibility information for the current page. || [http://www.brucelawson.co.uk/2009/rel-accessibility/ blog post] which itself uses the rel value in a <link> tag in the head of the document.

|-
| [[rel-author|author]] || indicate[s] that the destination of that hyperlink represents the author of the current page. Combines with [[rel-me|rel-me]] to chain authorship information. || Google has said it will index rel-Author in this [http://googlewebmastercentral.blogspot.com/2011/06/authorship-markup-and-web-search.html blog post], with further [http://www.google.com/support/webmasters/bin/answer.py?answer=1229920 discussion of the rel-me connection] See also [http://dev.w3.org/html5/spec/Overview.html#link-type-author the HTML5 spec]

|-
| [[rel-bibliography|bibliography]] || indicate[s] that the destination of that hyperlink is a bibliography for the current page. || [http://microformats.org/discuss/mail/microformats-discuss/2007-October/010863.html mailing list post, 2007-10-15]

|-
| [[rel-cite|cite]] || indicate[s] that the destination of that hyperlink is an authoritative source or a precedent to the current page. || [[distributed-conversation-brainstorming]]

|-
| [[rel-group|group]] || the referenced document represents a group to which the person represented by the current document belongs || [[group-brainstorming]]

|-
| <span id="longdesc">[[rel-longdesc|longdesc]]</span> || Alternative to the img longdesc attribute, for use on visible links || [http://www.google.com/search?q=rel%3D%22longdesc%22 Google search for rel=longdesc in the wild] shows many sources of proposals. Please edit this to list the earliest and perhaps most recent/comprehensive proposal. No known real world POSH usage in the wild yet.

|-
| [[rel-map|map]] || Link to a map. Possibly embedded within an adr, hCard, geo or hCalendar. Parsers {{may}} attempt to parse the URL if it is a link to a known map site (e.g. Geohash, Google Maps, Multimap) and extract co-ordinates and other useful data. || (to [[User:TobyInk|TobyInk]] by email)

|-
| [[rel-member|member]] || the referenced document represents a member of the group represented by the current document || [[group-brainstorming]]

|-
| [[rel-m_PageScroll2id|m_PageScroll2id]] || JS to scroll to a defined ID || [[group-brainstorming]]

|-
| [[rel-prefetch|prefetch]] || indicates the URL and content-type of a resource that is likely to be a required resource when the next action or navigation is triggered. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#prefetch resource hints draft]

|-
| [[rel-preload|preload]] || indicates the URL and content-type of a resource that should be fetched as early as possible by the user agent. Initiating an early fetch allows the user agent to mask the request latency of the resource and make it available sooner to the application.|| [https://igrigorik.github.io/resource-hints/#preload resource hints draft]

|-
| [[rel-prerender|prerender]] || indicates the URL of the next navigation target. Initiating a prerender allows the user agent to deliver an instant navigation experience: the user agent downloads the top-level resource and its assets, and performs all of the processing steps required to show the page without actually showing it to the user.|| [https://igrigorik.github.io/resource-hints/#prerender resource hints draft]

|-
| [[rel-profile|profile]] || indicate[s] that the destination of that hyperlink is a metadata profile (e.g. an [[XMDP]] profile) for the current page or portion thereof || [[xmdp-brainstorming]]

|-
| [[rel-shortlink|shortlink]] || the referenced document represents the current document but with a shorter URL || [http://samj.net/2009/04/introducing-relshort-better-alternative.html blog post]
|-
| source || the referenced document represents the source code for the current document or project || [[source-brainstorming]] [http://adactio.com/journal/6667/ blog post]

|-
| vcalendar-parent || link from an event to a containing event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-child || link from an event to a contained event || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]
|-
| vcalendar-sibling || link from an event to a related event with the same container || [[User:TobyInk/hcalendar-1.1|hCalendar 1.1 draft]]

|-
| [[rel-status|status]] || the referenced document represents the status (or source of status updates) for the author of this document || [http://monkinetic.com/2009/11/24/status-autodiscovery-relstatus.html blog post]

|-
| https://api.w.org/ || Link to Wordpress API || [https://wordpress.org/themes/twentysixteen/ Official Wordpress theme]

|}

=== more brainstorming ===
See also:
* [[genealogy-brainstorming]] for some thoughts on possible additional values for family relationships (use existing [[XFN]] [[rel-parent|parent]], [[rel-child|child]], [[rel-sibling|sibling]], [[rel-spouse|spouse]], [[rel-kin|kin]] values first though)
* [[xpn-brainstorming]] for some thoughts on possible additional values for professional relationships (use existing [[XFN]] [[rel-co-worker|co-worker]], [[rel-colleague|colleague]] values first though)

== POSH usage ==
There are numerous rel values used as [[POSH]], both in the wild, whose origins are not necessarily known, nor are their meanings consistent. There are also numerous rel values from external proposals of varying degrees of merit. It is useful to document their existence and summarize their implied meanings/usage intent as research that may be used to perhaps take one or more of them thru the microformats [[process]] if there is both sufficient interest and sufficient in the wild usage.

Note: If a value is missing from this table, it may have either already been promoted by writing it up as a proposal, or demoted by being explicitly dropped. Please check the other tables first before adding to this table.

Note: this list is incomplete, please help complete it from the following sources:

External sources:
* [http://developer.mozilla.org/about/meta Meta Information in DevMo Docs] (DevMo)
* [http://wiki.mozilla.org/Microsummaries Microsummary]
* [http://lachy.id.au/dev/markup/specs/wclr/ Web Communication Link Relationships] (WCLR)
* [http://www.w3.org/MarkUp/Relationships.html W3C Link Relationship values draft] (LRdraft) - from a draft of the HTML spec circa 1991.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes HTML5 draft] '''Liable to change'''
* [http://wiki.foaf-project.org/Autodiscovery FOAF Project Wiki: Autodiscovery] (FOAF)
* [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]
* [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google Blog]

{| border="1"
|+
! rel value !! summary !! origin !! proposal(s)

|-
| [[rel-archive|archive]] || index of archived entries || unknown, perhaps Wordpress open source blogging software || WCLR

|-
| [[rel-archives|archives]] || Provides a link to a collection of records, documents, or other materials of historical interest. || || HTML5

|-
|[[rel-author|author]]||see brainstorming above for suggested use by google||unknown || DevMo / HTML5

|-
| [[rel-canonical|canonical]] || To help search engines disambiguate the same page with multiple representations || Google || [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Google]/[http://www.bing.com/community/blogs/webmaster/archive/2009/02/12/partnering-to-help-solve-duplicate-content-issues.aspx Microsoft]/[http://www.ysearchblog.com/2009/02/12/fighting-duplication-adding-more-arrows-to-your-quiver/ Yahoo!], [http://blog.ask.com/2009/02/ask-is-going-canonical.html Ask Jeeves]

|-
| [[rel-comment|comment]] || … || … || WCLR

|-
| [[rel-contribution|contribution]] || … || … || WCLR

|-
| [[rel-edituri|EditURI]]
| Location of the xml-rpc gateway for a Wordpress install that allows external programs to add, edit and delete posts. Used by "[http://codex.wordpress.org/Weblog_Client WordPress blog client]" software for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. || Description stubbed in [[rel-edituri]].

|-
| [[rel-endorsed|endorsed]] || … || … || WCLR

|-
| [[rel-fan|fan]] || xxxx. || … || [[hcard-user-profile-authoring]]

|-
| [[rel-feed|feed]] || Gives the address of a syndication feed for the current document. || … || WCLR/ HTML5

|-
| [[rel-footnote|footnote]] || Location of the footnote on a link to a footnote. || Markdown preprocessors such as [http://maruku.rubyforge.org/ Maruku] || HTML5

|-
| [[rel-icon|icon]] || Imports an icon to represent the current document. (Allowed in <code>link</code> only) || [http://dev.w3.org/html5/spec-LC/links.html#rel-icon HTML5] || WCLR/HTML5

|-
| [[rel-kinetic-stylesheet|kinetic-stylesheet]] || Imports a [http://kssproject.org/ KSS] 'kinetic stylesheet' to bind dynamic behavior to elements || Used in the [http://plone.org Plone] Content Management System || …

|-
| [[rel-lightbox|lightbox]] || Hook - Indicates that following the link will trigger a "lightbox" script (Allowed in <code>link</code> only) || ([http://www.google.co.uk/search?q=rel%3D%22lightbox%22 Google search for rel=lightbox in the wild]) Use "lightbox" instead of "clearbox" or "prettyPhoto" || …

|-
| [[rel-made|made]] || … || … || LRdraft

|-
| [[rel-meta|meta]] || … || [http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#transport 1999 W3C RDF syntax REC] || FOAF

|-
| [[rel-microsummary|microsummary]]|| … || … ||[http://wiki.mozilla.org/Microsummaries Microsummary], be aware of: [[page-summary-formats#Issues_2|microsummary issues]]

|-
| [[rel-noreferrer|noreferrer]] || indicates that no referrer information is to be leaked when following the link. || [http://dev.w3.org/html5/spec-LC/links.html#rel-noreferrer HTML5] || HTML5

|-
| [[rel-openid-delegate|openid.delegate]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-openid-server|openid.server]] || … || ([http://www.google.co.uk/search?q=%22rel%3Dopenid%22 Google search for rel=openid.* in the wild]) || …

|-
| [[rel-permalink|permalink]] || indicate a permanent link for some, or all, content within the document. obsolete; use <code>bookmark</code> instead. || … || WCLR

|-
| [[rel-pgpkey|pgpkey]] || (see also rel-publickey) || … || [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html], [http://golem.ph.utexas.edu/~distler/blog/archives/000325.html]

|-
| [[rel-pingback|pingback]] || Gives the address of the pingback server that handles pingbacks to the current document. (Allowed in <code>link</code> only) || … || WCLR/ HTML5

|-
| [[rel-popover|popover]] || Used by a JS widget to display a large, descriptive tooltip. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#popovers Popover.js] || …

|-
| [[rel-prefetch|prefetch]] || Specifies that the target resource should be pre-emptively cached. (Allowed in <code>link</code> only) || … || HTML5

|-
| [[rel-privacy|privacy]] || Specifies that the target resource is the privacy policy. || … || …

|-
| [[rel-publickey|publickey]] || (see also rel-pgpkey) || … || [http://rasterweb.net/raster/2002/12/12/20021212072812/]

|-
| [[rel-referral|referral]] || … || … || WCLR

|-
| [[rel-related|related]] || … || … || WCLR

|-
| [[rel-replies|replies]] || indicates a continued thread || unknown || [http://www.apps.ietf.org/rfc/rfc4685.html RFC4685]

|-
| [[rel-respond-proxy|respond-proxy]] || Working with respond.js - proxy on external server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-respond-redirect|respond-redirect]] || Working with respond.js - redirect location on local server || [https://github.com/scottjehl/Respond] || [https://github.com/scottjehl/Respond]

|-
| [[rel-resource|resource]] || … || … || WCLR

|-
| [[rel-search|search]] || … || unknown || unknown

|-
| [[rel-sitemap|sitemap]] || Links to a site map document. || … || http://www.sitemaps.org/

|-
| [[rel-sponsor|sponsor]] || … || … || WCLR

|-
| [[rel-tooltip|tooltip]] || Used by a JS widget to display a tooltip similar (though more customizable) to what is shown by browsers if the 'title' attribute is present. || [http://twitter.github.com/bootstrap Twitter's Bootstrap] [http://twitter.github.com/bootstrap/javascript.html#tooltips Tooltip.js] (and likely other JS tools) || …

|-
| [[rel-trackback|trackback]] || … || unknown, perhaps open source Movable Type blogging software || WCLR

|-
| [[rel-unendorsed|unendorsed]] || (probably redundant to [[rel-nofollow|nofollow]]) || … || WCLR

|-
| [[rel-user|user]] || … || … || WCLR
|-
| [[rel-wlwmanifest|wlwmanifest]] || Used by "[http://explore.live.com/windows-live-writer Windows Live Writer]," a Microsoft [http://codex.wordpress.org/Weblog_Client blog client] for automating posting and updating blog content from your desktop. || Seen in [http://www.wordpress.org/ WordPress], e.g. [http://www.tom-watson.co.uk/]. Similar values are probably used by other blog content management systems as well. || …

|}

=== WCLR ===

The WCLR proposal is described by its author (in e-mail, 2007-09-25) as:

<blockquote>
<p>…now effectively obsolete, since HTML5 and Microformats cover all the worthwhile relationships in that already.</p>

These are [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-links.html#linkTypes covered by HTML5 already]:

* permalink -> bookmark
* archive -> archives
* feed
* pingback
* unendorsed -> nofollow

The rest now seem unnecessary.
</blockquote>

Nonetheless, there may be some mileage in using them in microformats, at least until HTML5 is widely available.

== Dublin Core ==
In the past, Dublin Core values have been added to this page in the table about HTML5 features, but no examples, nor an actual specification explicitly stating how the value(s) should be used in HTML could be found. The linked specifications below have been updated so we should start considering Dublin Core values accordingly.

{| border="1"
|+
! rel value !! summary !! source
|-
| schema.DC || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, with regard to the fifteen terms of the Dublin Core Metadata Element Set already published || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]

|-
| schema.DCTERMS || a specification of all metadata terms maintained by the Dublin Core Metadata Initiative, reflecting the changes described more fully in the 2012 document "Maintenance changes to DCMI Metadata Terms" [http://dublincore.org/usage/decisions/2012/dcterms-changes/] || [http://www.dublincore.org/documents/dcq-html/ Dublin Core]
|-
|}

'''Issues need updating given new information from linked resources.'''

Notes:
* Dublin Core. This search may help: [http://www.google.co.uk/search?as_q=rel%3Dschema.*&hl=en&num=10&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=http%3A%2F%2Fdublincore.org&as_rights=&safe=images].
** '''examples from that search only use invisible <code><link href></code> element'''. At first glance it appears the results from the search show only uses with the invisible <code><link href></code> element which is not ideal for content relationships. Content relationships should be user visible and thus uses with <code><a href></code> are strongly preferred.
*** [http://www.ietf.org/rfc/rfc2731.txt RFC2731] defines <code>rel="schema.AC"</code> and <code>rel="schema.RC"</code> with the pattern <code>rel="schema.PREFIX"</code> as a syntax for defining namespaces for use in meta[@name], *[@rel], *[@rev] and (as per eRDF) *[@class] attributes. A link to a Dublin Core metadata schema is generally not suitable for end users, so <code><link href></code> appears to be more appropriate than <code><a href></code> for those that use Dublin Core metadata schemas.
*** The scheme proposed above provides metadata namespace declarations. As described by DCMI specifications, such indications '''cannot''' be provided w/o a suitable namespace. In order to give complete pieces of information, the correct description set must be: <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> (for the namespace declaration, followed by) <code><meta name="DCTERMS.<nowiki>[element]</nowiki>" content="<nowiki>[element.value]</nowiki>"></code> for related elements.
**** Note: [http://purl.org/dc/terms/ schema.DCTERMS] is conventionally related to an upgraded elements list than [http://purl.org/dc/elements/1.1/ schema.DC] and should be preferred as rel values. Both are discussed here for subject completeness)
** '''proposal to use in content currently only theoretical'''. Thus unfortunately the use of Dublin Core in user visible content like <code><a href></code> appears to be strictly theoretical. See [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011445.html microformats-discuss/2008-January/011445.html] for a proposal to use Dublin Core in user visible content.
*** '''recent improvements'''. DCMI solves some trouble concerning metadata through the ''description set model''. Some of these informations cannot currently be provided in any standard ways other than DC, namely dates, validity and periodicity. Following this public bug report ([https://www.w3.org/Bugs/Public/show_bug.cgi?format=multiple&id=22520]), the correct namespace declaration for DC and DCTERMS metadata are now considered valid HTML code. We '''must''' encourage this practice both for internal usefulness and for shared practices.

* The Dublin Core document [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] is a specification for, and gives examples of, both <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> and <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">. Note that Dublin Core encourages the use of DCTERMS elements over DC. A list of projects which use Dublin Core metadata is maintained [http://dublincore.org/projects/ here].
* [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] also includes examples of <link rel="DCTERMS.[element]" href="">, where [element] = subject, isReferencedBy, creator, and publisher. The <link> tag is used instead of the <meta> tag whenever the content is a URL. (Note that this use is different from, but related to, <link rel="schema.DCTERMS" href="">.) Potentially, ''any'' of the 55 DCTERMS elements could be used in this way, and this could include use in HTML 5.
** As said before, HTML5 validators now allow the use of <code><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/"></code> for namespace declarations.

* According to DCMI specification linked above, as well as [http://dublincore.org/documents/dc-html/ "Expressing Dublin Core metadata using HTML/XHTML meta and link elements"] documentation, HTML5 @rel attribute proposed values table has been updated. It now includes a subset of DCMI ''/terms/'' namespace properties, more specifically those whose value can (or must) be logically expressed by a resource, so that the "href" attribute value becomes a non-literal value surrogate referring to the resource itself.
** Elements from ''/elements/1.1/'' namespace have not been included on purpose. According to [http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces "FAQ/DC and DCTERMS Namespaces"], the old namespace is maintained for legacy purposes only and it is not as suitable for non-literal values as the ones denoted by <code><link></code> elements.

== Use with HTTP Link Header ==
You can also use any of the rel values (that are allowed for link elements) with HTTP Link Headers,

Example: returning a Javascript file with a license (since JS itself has no way to indicate a license)
<syntaxhighlight lang=text>
Link: <http://creativecommons.org/publicdomain/zero/1.0/>; rel="license"
</syntaxhighlight>

For multiple licenses (e.g. CC-SA and GPL), simply use multiple <code>Link:</code> headers.
<syntaxhighlight lang=text>
Link: <http://creativecommons.org/licenses/by-sa/3.0/>; rel="license"
Link: <http://www.gnu.org/licenses/gpl.html>; rel="license"
</syntaxhighlight>

Example: similarly, linking to a copyright statement for an image:
<syntaxhighlight lang=text>
Link: <http://example.org/copyright.html>; rel="copyright"
</syntaxhighlight>
or providing a brief inline copyright statement:
<syntaxhighlight lang=text>
Link: <data:text/plain;charset=utf-8,Copyright 2013 ExampleCo, All Rights Reserved.>; rel="copyright"
</syntaxhighlight>

== unspecified ==
Some rel values have been added to this page perhaps in one of the tables above, but no examples, nor an actual specification explicitly stating that the value(s) should be used in the HTML 'rel' attribute could be found. They are listed here in the hopes someone can discover more specific/precise URLs to examples or specifications about them (preferably both). Until such precise URLs to examples/specs are provided, the values can be treated as they are purely theoretical and thus of little interest.

A simple list here is sufficient.

== non HTML rel values ==
There are markup languages other than HTML that also have a rel attribute, often based upon the HTML rel attribute.
It is useful to document some of these other languages and their rel values for both reference purposes, and to provide background research for the possible development and re-use of these values in HTML, as [[poshformats]] or [[microformats]]

Sources:
* [[Atom]] [[RFC4287]] specification.
* See http://www.iana.org/assignments/link-relations.html for more.
* See [http://amundsen.com/media-types/maze/format/#link-relations Maze+XML]
* See [http://amundsen.com/media-types/collection/format/#link-relations Collection+JSON]
* See [http://www.opensearch.org/Specifications/OpenSearch/1.1#Url_rel_values OpenSearch]
* See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]
* See [http://rels.messages.io Workflow-Related Link Relations at Messages.io]

{| border="1"
|+
! rel value !! summary<br />(from the relevant specification where possible)) !! defining specification

|-
| self
| From http://www.ietf.org/rfc/rfc4287.txt : <blockquote>The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.</blockquote>
| [[Atom]] http://www.ietf.org/rfc/rfc4287.txt

|-
| http://gdata.youtube.com/schemas/2007#in-reply-to || See http://code.google.com/apis/youtube/2.0/developers_guide_protocol_comments.html || YouTube extension to Atom

|-
| collection || Refers to a resource which represents a collection of which the current resource is a member.

When used in the Maze+XML media type, the associated URI returns the available collection of mazes.
|| Maze+XML, Collection+JSON, OpenSearch

|-
| compensatingtx || Link to a resource representing information about a compensating transaction for each member transaction of a [http://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf Long-Lived Compensating Transaction] || See [http://rels.messages.io/#compensatingtx Compensating Transaction Link Relation]

|-
| east || Refers to a resource to the "east" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the east in the active maze.

|| Maze+XML

|-
| events || Link to a collection resource representing a list of subscribe-able events. || See [http://rels.messages.io/#events Events Link Relation]

|-
| exit || Refers to a resource that represents the exit or end of the current client actvity or process.

When used in the Maze+XML media type, the associated URI points to the final exit resource of the active maze.

|| Maze+XML

|-
| north || Refers to a resource that is "north" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the north in the active maze.

|| Maze+XML

|-
| south || Refers to a resource that is "south" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the south in the active maze.

|| Maze+XML

|-
| [[rel-via|via]] || Identifies a resource that is the source of the information in the context. || Atom 1.0 Syndication format (RFC 4287)

|-
| west || Refers to a resource that is "west" of the current resource.

When used in the Maze+XML media type, the associated URI points to a neighboring cell resource to the west in the active maze.

|| Maze+XML

|-
| item || The target IRI points to a resource that is a member of a collection represented by the context IRI. || Collection+JSON

|-
| create-form || When included in a resource, the "create-form" link relation MAY identify a target resource that represents the form to append a new member to the link context. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| edit-form || When included in a resource, the "edit-form" link relation identifies a target resource that represents the form for editing associated resource. || See [http://tools.ietf.org/html/rfc6861 The Create-Form and Edit-Form Link Relations (RFC6861)]

|-
| lightframe || Opens the target in a lightbox. On inclusion it provides a simple target the lightframe and loads the content in a lightbox effect || Lightbox

|-
| superbox[image] || jQuery Superbox! is a script which allows you display windows with the lightbox effect. || superbox

|-
| wp-video-lightbox || wp-video-lightbox! is a rel to anchor tag script display videos with the lightbox effect. || wp-video-lightbox

|-
| youtube || Opens the target youtube video in using the Swipebox Plugin || Swipebox

|-
| shadowbox || shadowbox is a jQuery script for images displaying with the "lightbox" effects. || shadowbox

|-
| permission || When included in a resource, the "permission" link relation MAY identify a target resource that represents the list of entities that can access or modify the resource in the link context. || See [http://cdoc.io/spec.html#permission-link-relation Collection Document Media Type Specification]

|-
| sub || When included in a resource representation of an event, the "sub" (subscription) link relation MAY identify a target resource that represents the ability to subscribe to the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#sub Subscription Link Relation]

|-
| unsub || When included in a resource representation of an event, the "unsub" (subscription cancellation) link relation MAY identify a target resource that represents the ability to un-subscribe from the pub/sub event-type resource in the link context. || See [http://rels.messages.io/#unsub Subscription Cancellation Link Relation]

|-
| version-history
| When included on a versioned resource, this link points to a resource containing the version history for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| latest-version
| When included on a versioned resource, this link points to a resource containing the latest (e.g., current) version.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy
| When included on a versioned resource, this link points to a working copy for this resource.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| working-copy-of
| When included on a working copy, this link points to the versioned resource from which this working copy was obtained.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| predecessor-version
| When included on a versioned resource, this link points to a resource containing the predecessor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| successor-version
| When included on a versioned resource, this link points to a resource containing the successor version in the version history.
| [http://tools.ietf.org/html/rfc5829 RFC 5829]

|-
| ... || ... || ...

|}

== dropped ==
The following rel values were in earlier version(s) of specification(s) and it is presumed by their absence from the most recent version of the respective specification(s) that they have been deprecated or obsoleted.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

In particular:
* if a rel value was in a draft and is missing (without explanation) from the final spec, or
* if a rel value was in a previous version of and is missing (without explanation) from an update to the specification (even a draft update)

Then absent any other information or explanation, it is presumed that the group/editors working on that specification decided to explicitly drop it (either in development, or in the updated version) and thus it should be obsoleted (not re-registered).

If you wish to add them, please research <em>why</em> such values were omitted from latter specifications before doing so. If you do discover the reasoning, please add a short statement or link to thereof into the appropriate place in the following table.

If there is more data, e.g. a link to an email of discussion of the spec development that explains ''why'' the rel value was dropped, and it explicitly states, e.g. it was without prejudice, or merely post-poned, or perhaps expected to be spun-out into its spec (or some other explicit positive reason), then it makes to link/cite that explicit text as part of a proposal.

Sources:
* [http://www.w3.org/MarkUp/html3/ HTML3] (HTML3) / has been superceded by [http://www.w3.org/MarkUp/Wilbur/ HTML 3.2] - which itself has been superceded by [http://www.w3.org/TR/REC-html40 HTML 4.0] - which itself has been updated by [http://w3.org/TR/html401 HTML 4.01], commonly referred to as "HTML 4" in this wiki and other places.)
* [http://www.w3.org/TR/relations.html Proposed HTML 4.0 link types] (HTML4dropped) - obsoleted/superceded by the HTML 4.0 Recommendation. Any values that were in the "Proposed HTML 4.0 link types" document but didn't make it into the HTML 4.0 Recommendation were thus explicitly dropped and should be avoided.

{| border="1"
|+
! rel value !! summary !! defining specification !! why dropped

|-
|[[rel-banner|banner]]||Was used to reference another document to be used as banner for this document (i.e. a form of "include" statement).|| HTML3 ||unknown

|-
| [[rel-begin|begin]] || identifies the author-defined start of a sequence of documents of which the current document is a node.
|| HTML4dropped||unknown

|-
| [[rel-biblioentry|biblioentry]] || identifies a bibliographic entry || HTML4dropped||unknown

|-
| [[rel-bibliography|bibliography]] || identifies a bibliography || HTML4dropped||unknown

|-
| [[rel-child|child]] (obsolete/superceded) || the target document is a hierarchical child, or subdocument, of the current document|| HTML4dropped||unknown

|-
| [[rel-citation|citation]] || the target is a bibliographic citation || HTML4dropped||unknown

|-
| [[rel-collection|collection]] || the target document is an collection that contains the current document || HTML4dropped||unknown

|-
| [[rel-definition|definition]] || identifies a definition of a term || HTML4dropped||unknown

|-
| [[rel-disclaimer|disclaimer]] || identifies a hypertext link to a legal disclaimer || HTML4dropped||unknown

|-
| [[rel-editor|editor]] || identifies a hypertext link to an editor || HTML4dropped||unknown

|-
| [[rel-end|end]] || identifies the author-defined end of a sequence of documents of which the current document is a node. || HTML4dropped||unknown

|-
| [[rel-footnote|footnote]] || the anchor is a footnote marker and the target is a footnote || HTML4dropped||unknown

|-
| [[rel-navigate|navigate]] || the target document contains information such as a image map that will help users to gain a sense of how and where to found information || HTML4dropped||unknown

|-
| [[rel-origin|origin]] || synonym for <code>top</code> || HTML4dropped||unknown

|-
| [[rel-parent|parent]] (obsolete/superceded) || the target document is the hierarchical parent, or container, of the current document|| HTML4dropped||unknown

|-
| [[rel-pointer|pointer]] || the target is a pointer to the real target. This value can be used by a user agent to perform a pre-fetch of the specified target for evaluation until the real target is reached || HTML4dropped||unknown

|-
| [[rel-publisher|publisher]] || identifies a hypertext link to a publisher || HTML4dropped||unknown

|-
| [[rel-sibling|sibling]] (obsolete/superceded) || the target document is a child of a common parent, or a hierarchical peer of the current document|| HTML4dropped||unknown

|-
| [[rel-top|top]] || the target document is the logical top node of the tree (see also <code>begin</code>) || HTML4dropped||unknown

|-
| [[rel-trademark|trademark]] || identifies a hypertext link to a trademark notice || HTML4dropped||unknown

|-
| [[rel-translation|translation]] || the target is a translation to another language || HTML4dropped||unknown

|-
| [[rel-urc|urc]] || identifies a Universal Resource Citation || HTML4dropped||unknown

|-
|}

== dropped without prejudice ==
In one known instance (from HTML4 to HTML5), some rel values were in an earlier version of a specification (or a proposal) and were dropped from a latter (draft) version, and it was noted that these values were dropped with the intent that they could still be proposed in a registry and thus they explicitly were not deprecated or obsoleted. This section documents such values as separate from the [[#dropped|dropped]] section.

In general, you {{should not}} use any dropped values.

If any such values have been superceded by standard values (see the first table on this page), then you {{must not}} use the dropped versions.

Rel values that were dropped without prejudice from a specification will be considered similar to new values that have never been specified.

If you know of additional rel values that were dropped without prejudice from an update to a specification, please cite a URL and quote from the group developing the specification that officially states from that group that the dropping of the values was done without prejudice, or equivalent statement (such as explicit allowance of external registration, proposal, and/or development).

This table serves a historical purpose. If you wish to propose a value from this table, please copy it and leave it in place.

Sources:
* Several rel values were [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7475#c15 explicitly dropped from HTML5]. Per: [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Issue 118 Decision] ('''emphasis''' added): <blockquote><p>"The final proposal argues for the removal of some relation values, to wit, it suggests removal of '''index, up, first and last'''. It was pointed out in survey comments that these relations are already registered in the IANA link relation registry. Presumably, '''these relations could also be entered in whatever other registry or registries HTML5 adopts for this purpose'''.</p>...<p>"Next Steps</p>...<p>"Since the relations to be removed are already registered at the IANA link relation registry, no further action is needed to include them there. WG members are '''free to register or record these relations elsehwere''' [sic], as well."</p></blockquote>

{| border="1"
|+
! rel value
! summary
! defining specification
! why dropped

|-
| [[rel-first|first]]
| Synonym for <code>start</code>
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-index|index]]
| Refers to a document providing an index for the current document.
| was in [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]; the token has been re-registered within the [[#HTML5_link_type_extensions|HTML5 link type extensions]] and is now valid.
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-last|last]]
| Refers to the last document in a collection of documents.
| HTML4dropped - never in an official spec
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
| [[rel-up|up]]
| When the document forms part of a hierarchy, this link references the immediate parent of the current document. Synonym for <code>parent</code>.
| was in [http://www.w3.org/MarkUp/html3/dochead.html HTML3] - but [http://www.w3.org/TR/html401/types.html#type-links dropped in HTML4]
| [http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html Explicitly dropped from HTML5 interim draft yet permitted for external registry]

|-
|}

See related [http://dev.w3.org/html5/spec/links.html#linkTypes HTML5: Link types] for existing HTML5 specified rel values.

== rejected ==
Some rel values have been proposed and rejected. They are listed here to make that explicit. Authors {{must not}} use rejected rel values.

Source: [[rejected-formats]].

{| border="1"
|+
! rel value !! origin / proposal !! why rejected
|-
| [[rel-logo|logo]]
| [http://relogo.org Relogo.org]
| [[rejected-formats#Logo]]
|-
|[[rel-pavatar|pavatar]] || [http://pavatar.com/ pavatar] || [[rejected-formats#Pavatar]]
|-
|}

== tools ==
See [[implementations]].

== addtional external research ==
Here are some additional historical references to the development or rel-values which may be useful when researching values, especially why specific values may have been proposed but abandoned.
* 1996-06-07 [http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt Hypertext links in HTML] (copies: [http://ftp.ics.uci.edu/pub/ietf/html/draft-ietf-html-relrev-00.txt ftp.ics.uci.edu])
* 1996-11-13 [http://www.w3.org/Architecture/NOTE-link Describing and Linking Web Resources]
* 1997-01-23 [http://lists.gnu.org/archive/html/lynx-dev/1997-01/msg00537.html LYNX-DEV Lynx and the LINK tag]
* 1997-01-24 [http://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jan/0357.html Taxonomy list]
* 1997-03-28 [http://www.w3.org/TR/WD-htmllink-970328 W3C Working Draft: Hypertext Links and Meta Information in HTML]

=== previous attempts at documenting ===
There have been previous attempts at documenting known rel values, most of which fell out of date due to being dependent on a single author maintaining them. They're listed here purely for historical reasons, and are not sufficient to be references of their own (since they're just individual curations of other references)
* [http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html Link Type Definitions Glossary] by fantasai
* ...

== related ==
{{rel-related-pages}}
* [[elemental-microformats]]
* [[existing-rev-values]]
* [[existing-class-names]]

== copyright ==

{{cc-pd-license}}

h-recipe

2022-11-30T23:52:01Z

Btrem: Fix: corrects syntaxhightlight lang attributes

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<syntaxhighlight lang=html>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</syntaxhighlight>

Parsed JSON:
<syntaxhighlight lang=json>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</syntaxhighlight>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==

=== Core Properties ===

The following core h-entry properties have broad consensus and are broadly interoperably published and consumed:

h-recipe properties, inside an element with class '''h-recipe''':

* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

=== Experimental properties with wide adoption ===
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

=== Proposed properties ===

The following properties are proposed additions based on various use-cases but are awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:

* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

h-recipe

2022-11-30T23:51:22Z

Btrem: Fix: replaces deprecated <source> tag with <syntaxhighlight>

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<syntaxhighlight lang=html4strict>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</syntaxhighlight>

Parsed JSON:
<syntaxhighlight lang=javascript>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</syntaxhighlight>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==

=== Core Properties ===

The following core h-entry properties have broad consensus and are broadly interoperably published and consumed:

h-recipe properties, inside an element with class '''h-recipe''':

* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

=== Experimental properties with wide adoption ===
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

=== Proposed properties ===

The following properties are proposed additions based on various use-cases but are awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:

* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

microformats2-parsing

2022-11-30T23:49:31Z

Btrem: Fix: corrects syntaxhightlight lang attributes

{{DISPLAYTITLE:microformats2 parsing specification}}
<dfn style="font-style:normal;font-weight:bold">[[microformats2]]</dfn> is a simple, open format for marking up data in HTML. The microformats2 parsing specification describes how to [[#implementations|implement]] a microformats2 parser, independent of any specific vocabularies.

;<span id="status">Status</span>
:This is a '''Living Specification''' with several interoperable [[#implementations|implementations]]. This specification is stable, subject to editorial changes only for improving clarity of existing meaning. While substantive changes are unexpected, it is a living specification subject to substantive change by issues and errata filed in response to implementation experience, requiring consensus among participating implementers (since 2015-01-21) as part of an explicit [[#change_control|change control]] process. There are currently no draft or proposed new features in this specification, and if any were to be added, they would be explicitly labeled as such.<br/>Note: This specification is only marked as a "Draft Specification" because of pending edits from [[microformats2-parsing-issues|resolved issues before 2016-06-20]]. Once those edits have been completed, the link to <nowiki>[[Category:Draft Specifications]]</nowiki> at the bottom of this document should be changed to <nowiki>[[Category:Specifications]]</nowiki>.
;Participate
:<span id="issues">[https://github.com/microformats/microformats2-parsing/issues Open Issues]</span>
:[[microformats2-parsing-issues|Resolved issues before 2016-06-20]]
:[[IRC]]: [irc://irc.libera.chat/microformats #microformats on Libera]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__
== algorithm ==
=== parse a document for microformats ===
To parse a document for microformats, follow the HTML parsing rules and do the following:
* start with an empty JSON "items" array and "rels" & "rel-urls" hashes:
<syntaxhighlight lang=json>
{
"items": [],
"rels": {},
"rel-urls": {}
}
</syntaxhighlight>
* parse the root element for class microformats, adding to the JSON items array accordingly
* parse all hyperlink (<code><a> <area> <link></code>) elements for rel microformats, adding to the JSON rels & rel-urls hashes accordingly
* return the resulting JSON
Parsers may simultaneously parse the document for both class and rel microformats (e.g. in a single tree traversal).

=== parse an element for class microformats ===
To parse an element for class microformats:
* parse element class for root class name(s) "h-*" and if none, backcompat root classes
** if none found, parse child elements for microformats (depth first, doc order)
** else if found, start parsing a new microformat
*** keep track of whether the root class name(s) was from backcompat
*** create a new { } structure with:
**** <code>type: <nowiki>[array of unique microformat "h-*" type(s) on the element sorted alphabetically]</nowiki>,</code>
**** <code>properties: { } </code> - to be filled in when that element itself is parsed for microformats properties
**** if the element has a non-empty <code>id</code> attribute:
***** <code>id:</code> string value of element's id attribute
*** parse child elements (document order) by:
**** if parsing a backcompat root, parse child element class name(s) for backcompat properties
**** else parse a child element class for property class name(s) "p-*,u-*,dt-*,e-*"
**** if such class(es) are found, it is a property element
***** add properties found to current microformat's <code>properties: { } </code> structure
**** parse a child element for microformats (recurse)
***** if that child element itself has a microformat ("h-*" or backcompat roots) and is a property element, add it into the array of values for that property as a { } structure, add to that { } structure:
****** <code>value</code>:
******* if it's a <code>p-*</code> property element, use the first p-name of the h-* child
******* else if it's an <code>e-*</code> property element, re-use its { } structure with existing <code>value:</code> inside.
******* else if it's a <code>u-*</code> property element and the h-* child has a u-url, use the first such u-url
******* else use the parsed property value per p-*,u-*,dt-* parsing respectively
***** else add found elements that are microformats to the "children" array
*** imply properties for the found microformat (see below)

The "*" for root (and property) class names consists of an optional vendor prefix (series of 1+ number or lowercase a-z characters i.e. <code>[0-9a-z]+</code>, followed by '-'), then one or more '-' separated lowercase a-z words.

=== parse an element for properties ===

==== parsing a <code>p-</code> property ====

To parse an element for a <code>p-x</code> property value (whether explicit <code>p-*</code> or backcompat equivalent):

* Parse the element for the [[value-class-pattern]]. If a value is found, return it.
* If <code>abbr.p-x[title]</code> or <code>link.p-x[title]</code>, return the <code>title</code> attribute.
* else if <code>data.p-x[value]</code> or <code>input.p-x[value]</code>, then return the <code>value</code> attribute
* else if <code>img.p-x[alt]</code> or <code>area.p-x[alt]</code>, then return the <code>alt</code> attribute
* else return the <code>textContent</code> of the element after:
** dropping any nested <code><script></code> & <code><style></code> elements;
** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present; otherwise their <code>src</code> attribute, if present, adding a space at the beginning and end, resolving the URL if it’s relative;
** removing all leading/trailing whitespace

==== parsing a <code>u-</code> property ====

To parse an element for a <code>u-x</code> property value (whether explicit <code>u-*</code> or backcompat equivalent):

* if <code>a.u-x[href]</code> or <code>area.u-x[href]</code> or <code>link.u-x[href]</code>, then get the <code>href</code> attribute
* else if <code>img.u-x[src]</code> return the result of "parse an img element for src and alt" (see Sec.1.5)
* else if <code>audio.u-x[src]</code> or <code>video.u-x[src]</code> or <code>source.u-x[src]</code> or <code>iframe.u-x[src]</code>, then get the <code>src</code> attribute
* else if <code>video.u-x[poster]</code>, then get the <code>poster</code> attribute
* else if <code>object.u-x[data]</code>, then get the <code>data</code> attribute
* else parse the element for the [[value-class-pattern]]. If a value is found, get it
* else if <code>abbr.u-x[title]</code>, then get the <code>title</code> attribute
* else if <code>data.u-x[value]</code> or <code>input.u-x[value]</code>, then get the <code>value</code> attribute
* else get the <code>textContent</code> of the element after removing all leading/trailing whitespace and nested <code><script></code> & <code><style></code> elements
* return the normalized absolute URL of the gotten value, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

==== parsing a <code>dt-</code> property ====

To parse an element for a <code>dt-x</code> property value (whether explicit <code>dt-*</code> or backcompat equivalent):

* parse the element for the [[value-class-pattern]], including the date and time parsing rules. If a value is found, then return it.
* if <code>time.dt-x[datetime]</code> or <code>ins.dt-x[datetime]</code> or <code>del.dt-x[datetime]</code>, then return the <code>datetime</code> attribute
* else if <code>abbr.dt-x[title]</code>, then return the <code>title</code> attribute
* else if <code>data.dt-x[value]</code> or <code>input.dt-x[value]</code>, then return the <code>value</code> attribute
* else return the <code>textContent</code> of the element after removing all leading/trailing whitespace and nested <code><script></code> & <code><style></code> elements.

==== parsing an <code>e-</code> property ====
To parse an element for a <code>e-x</code> property value (whether explicit "<code>e-*"</code> or backcompat equivalent):

* return a dictionary with two keys:
** <code>html</code>: the <code>innerHTML</code> of the element by using the [https://html.spec.whatwg.org/multipage/parsing.html#serialising-html-fragments HTML spec: Serializing HTML Fragments algorithm], with leading/trailing whitespace removed.
** <code>value</code>: the <code>textContent</code> of the element after:
*** dropping any nested <code><script></code> & <code><style></code> elements;
*** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present; otherwise their <code>src</code> attribute, if present, adding a space at the beginning and end, resolving the URL if it’s relative;
*** removing all leading/trailing whitespace

==== parsing for implied properties ====

Imply properties only on explicit <code>h-x</code> class name root microformat element (no backcompat roots):

* if no explicit "<code>name</code>" property, and no other <code>p-*</code> or <code>e-*</code> properties, and no nested microformats,
* then imply by:
** if <code>img.h-x</code> or <code>area.h-x</code>, then use its <code>alt</code> attribute for name
** else if <code>abbr.h-x[title]</code> then use its <code>title</code> attribute for name
** else if <code>.h-x>img:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>img</code>’s <code>alt</code> for name
** else if <code>.h-x>area:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>area</code>’s <code>alt</code> for name
** else if <code>.h-x>abbr:only-child[title]:not([title=""]):not[.h-*]</code> then use that <code>abbr</code> <code>title</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>img:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>img</code>’s <code>alt</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>area:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>area</code>’s <code>alt</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>abbr:only-child[title]:not([title=""]):not[.h-*]</code> use that <code>abbr</code>’s <code>title</code> for name
** else use the <code>textContent</code> of the <code>.h-x</code> for <code>name</code> after:
*** dropping any nested <code><script></code> & <code><style></code> elements;
*** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present;
** remove all leading/trailing whitespace
* if no explicit "<code>photo</code>" property, and no other explicit <code>u-*</code> properties, and no nested microformats,
* then imply by:
** if <code>img.h-x[src]</code>, then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>object.h-x[data]</code> then use <code>data</code> for photo
** else if <code>.h-x>img[src]:only-of-type:not[.h-*]</code> then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>.h-x>object[data]:only-of-type:not[.h-*]</code> then use that <code>object</code>’s <code>data</code> for photo
** else if <code>.h-x>:only-child:not[.h-*]>img[src]:only-of-type:not[.h-*]</code>, then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>.h-x>:only-child:not[.h-*]>object[data]:only-of-type:not[.h-*]</code>, then use that <code>object</code>’s <code>data</code> for photo
** if there is a gotten photo value, return the normalized absolute URL of it, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).
* if no explicit "<code>url</code>" property, and no other explicit <code>u-*</code> properties, and no nested microformats,
* then imply by:
** if <code>a.h-x[href]</code> or <code>area.h-x[href]</code> then use that <code>[href]</code> for url
** else if <code>.h-x>a[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>area[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>:only-child:not[.h-*]>a[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>:only-child:not[.h-*]>area[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** if there is a gotten url value, return the normalized absolute URL of it, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

<strong>Note:</strong> The same markup for a property should not be causing that property to occur in <em>both</em> a microformat and one embedded inside - such a property should only be showing up on one of them. The parsing algorithm has details to prevent that, such as the <code>:not[.h-*]</code> tests above.

=== parse a hyperlink element for rel microformats ===
To parse a hyperlink element (e.g. a or link) for rel microformats: use the following algorithm or an algorithm that produces equivalent results:
* if the "rel" attribute of the element is empty then exit
* set url to the value of the "href" attribute of the element, normalized to be an absolute URL following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element if any).
* treat the "rel" attribute of the element as a space separate set of rel values
* for each rel value (rel-value)
** if there is no key rel-value in the rels hash then create it with an empty array as its value
** if url is not in the array of the key rel-value in the rels hash then add url to the array
* end for
* if there is no key with name url in the top-level "rel-urls" hash then add a key with name url there, with an empty hash value
* add keys to the hash of the key with name url for each of these attributes (if present) and key not already set:
** "hreflang": the value of the "hreflang" attribute
** "media": the value of the "media" attribute
** "title": the value of the "title" attribute
** "type": the value of the "type" attribute
** "text": the text content of the element if any
* if there is no "rels" key in that hash, add it with an empty array value
* set the value of that "rels" key to an array of all unique items in the set of rel values unioned with the current array value of the "rels" key, sorted alphabetically.

==== rel parse examples ====
Here are some examples to show how parsed rels may be reflected into the JSON (empty items key).

E.g. parsing this markup:
<syntaxhighlight lang=html>
<a rel="author" href="http://example.com/a">author a</a>
<a rel="author" href="http://example.com/b">author b</a>
<a rel="in-reply-to" href="http://example.com/1">post 1</a>
<a rel="in-reply-to" href="http://example.com/2">post 2</a>
<a rel="alternate home"
href="http://example.com/fr"
media="handheld"
hreflang="fr">French mobile homepage</a>
</syntaxhighlight>

Would generate this JSON:
<syntaxhighlight lang=json>
{
"items": [],
"rels": {
"author": [ "http://example.com/a", "http://example.com/b" ],
"in-reply-to": [ "http://example.com/1", "http://example.com/2" ],
"alternate": [ "http://example.com/fr" ],
"home": [ "http://example.com/fr" ]
},
"rel-urls": {
"http://example.com/a": {
"rels": ["author"],
"text": "author a"
},
"http://example.com/b": {
"rels": ["author"],
"text": "author b"
},
"http://example.com/1": {
"rels": ["in-reply-to"],
"text": "post 1"
},
"http://example.com/2": {
"rels": ["in-reply-to"],
"text": "post 2"
},
"http://example.com/fr": {
"rels": ["alternate", "home"],
"media": "handheld",
"hreflang": "fr",
"text": "French mobile homepage"
}
}
}
</syntaxhighlight>

=== parse an img element for src and alt ===
To parse an <code>img</code> element for <code>src</code> and <code>alt</code> attributes:
* if <code>img[alt]</code>
** return a new <code>{}</code> structure with
*** <code>value</code>: the element's <code>src</code> attribute as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).
*** <code>alt</code>: the element's <code>alt</code> attribute
* else
** return the element's <code>src</code> attribute as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

== what do the CSS selector expressions mean ==
''This section is non-normative.''

Use [http://gallery.theopalgroup.com/selectoracle/ SelectORacle] to expand any of the above CSS selector expressions into longform English prose.

Exception:
* ''':not[.h-*]''' is not a valid CSS selector but is used here to mean:
** does not have any class names that start with "h-"

== note HTML parsing rules ==
''This section is non-normative.''

microformats2 parsers are expected to follow HTML parsing rules, which includes for example:
* ignore <code><template></code> elements - stuff between <code><template></code> tags don't end up in the DOM
** test-case in the wild: http://sixtwothree.org/blog/now-accepting-webmentions/

== note backward compatibility details ==
The parsing algorithm and details refer to "backcompat root classes" (backcompat roots for short) and "backcompat properties". These conditions and steps in the algorithm document how to parse pre-microformats2 microformats which all defined their own specific root class names and explicit sets of properties.

Some details to be aware of (which are explicitly in the algorithm, this is just an informal summary)
* If an element has one or more microformats2 root class name(s) (<code>h-*</code>)
** all backcompat root class names are ignored on that element.
** all backcompat properties, without an intervening root class name, are ignored inside that element
* If an element has only a backcompat root class name (or names)
** all microformats2 property class names (p-* u-* dt-* e-*), without an intervening element with root class name, are ignored inside that element
** there is no implied property value parsing (p-name, u-url, u-photo) for that element

=== backward compatibility mappings ===
Note: several parser implementations have encoded backward compatible mappings into source and data files. Implementers of parsers may find these useful:
* search for "modules.maps[" in https://github.com/glennjones/microformat-shiv/blob/master/microformat-shiv.js
* search for "$classicPropertyMap" in https://github.com/indieweb/php-mf2/blob/master/Mf2/Parser.php
* https://github.com/tommorris/mf2py/blob/master/mf2py/backcompat.py

== questions ==
See the FAQ:
* [[microformats2-parsing-faq]]

== implementations ==
{{main|microformats2#Implementations}}
There are open source [[microformats2#Implementations|microformats2 parsers]] available for Javascript, node.js, PHP, Ruby and Python.

== test suite ==
See:
* https://github.com/microformats/tests
* https://github.com/indieweb/php-mf2/tree/master/tests/Mf2

Ports to/for other languages encouraged.

== change control ==
Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.

Per the stable status of this document, substantive issue filing, resolution, and edits are done with the following change control steps, which may nearly all be done asynchronously once an issue is filed to reach the required state of "Resolve by implementation verified rough consensus". All steps should be openly documented (e.g. on this wiki or GitHub issues) such that others may later verify the history of an issue, and all steps are encouraged to be announced on #microformats [[IRC]] with a link to the issue.

* '''File an issue.''' Anyone may file a new [[microformats2-parsing-issues|issue]] and is encouraged to do so, with the caveat that per the stable status, only issues originating as a result of implementation experience are likely to have a substantive impact on this specification.
* '''Propose a resolution.''' Anyone may propose resolutions to existing issues, and should encourage others in the community, especially implementers, to provide feedback. Proposed resolutions should include what specific text of the spec needs changing, preferably with replacement text, and test cases if applicable (e.g. a resolution could just document the current state more precisely without needing to provide any new test cases).
* '''Provide feedback on proposed resolution(s).''' Anyone may provide feedback on proposed resolutions with their name attached, in summary (e.g. +1/0/-1 opinions), and additionally with reasoning (required for objections, optional otherwise), or optionally with suggested improvements, or counter-proposals (per "Propose a resolution" above).
* '''Iterate to resolve objections if any.''' If there are any objections to a proposed resolution, proposer(s) and anyone agreeing should work to iterate on the proposal to resolve objections to the satisfaction (or at least withdrawal of objection) of anyone objecting. The more objections resolved the better, and incremental progress is forward progress.
* '''Broaden implementer consensus.''' Proposer(s) and anyone agreeing should reach out (e.g. via #microformats [[IRC]]) to multiple implementers of the specification to get their opinions and feedback on proposal(s). The more implementers providing feedback the better. Iterate to resolve any new objections per "Iterate to resolve objections if any" above.
* '''Encourage and get 1+ implementation(s).''' Encourage, get, and document 1+ implementation(s) of implementation affecting aspects of a proposed resolution, preferably with a test case if applicable.
* '''Resolve by implementation verified rough consensus.''' Once there is rough consensus on a proposal (where <dfn>rough consensus</dfn> means <strong>either no objections, or at a minimum no objections by implementers, and explicit positive opinions by 2+ implementers</strong>) and a proposal's feasibility is verified by at least 1 implementation of aspects of the proposal that affect implementations (none needed if there are none, e.g. purely editorial), cite those in a "Resolution:" statement on the issue (e.g. in a comment), and explicitly share this resolution statement and link to issue in the #microformats [[IRC]] channel.
* '''Edit specification.''' Normally the spec editor(s) will make edits per implementation verified rough consensus resolutions, however anyone (though especially issue discussion participants) may make a specification edit per a resolution if they are able to verify the citations that the resolution has achieve rough consensus, and has 1+ implementation(s) per "Encourage and get 1+ implementation(s)" above. Edits must contain a "Summary" field entry that at a minimum mention the issue by name, should provide a URL to the issue resolution, and preferably be done by a spec editor or an implementer. Once the edit is made, the issue should be closed, or at least a comment made on the issue requesting that the opener of the issue close the issue.

These change control steps are inspired by the tradition of "Rough consensus and running code" as exhibited by example by IETF and W3C processes, and in that regard, seek to be a philosophically compatible approach to specification iteration. They have been in rough practice since 2015-01-21, increasingly strictly applied since then with consensus of issue discussion participants, and explicitly documented based on issue resolving and spec editing experience.

== see also ==
* [[microformats2]]
* [[microformats2-parsing-faq]]
* [[microformats2-parsing-issues]]
* [[microformats2-parsing-brainstorming]] - for background, thinking, exploring possibilities
* [[microformats2-parsing-rdf]]
* [[microformats2-implied-properties]]

[[Category:Draft Specifications]]

microformats2-parsing

2022-11-30T23:46:07Z

Btrem: Fix: replaces deprecated <source> tag with <syntaxhighlight>

{{DISPLAYTITLE:microformats2 parsing specification}}
<dfn style="font-style:normal;font-weight:bold">[[microformats2]]</dfn> is a simple, open format for marking up data in HTML. The microformats2 parsing specification describes how to [[#implementations|implement]] a microformats2 parser, independent of any specific vocabularies.

;<span id="status">Status</span>
:This is a '''Living Specification''' with several interoperable [[#implementations|implementations]]. This specification is stable, subject to editorial changes only for improving clarity of existing meaning. While substantive changes are unexpected, it is a living specification subject to substantive change by issues and errata filed in response to implementation experience, requiring consensus among participating implementers (since 2015-01-21) as part of an explicit [[#change_control|change control]] process. There are currently no draft or proposed new features in this specification, and if any were to be added, they would be explicitly labeled as such.<br/>Note: This specification is only marked as a "Draft Specification" because of pending edits from [[microformats2-parsing-issues|resolved issues before 2016-06-20]]. Once those edits have been completed, the link to <nowiki>[[Category:Draft Specifications]]</nowiki> at the bottom of this document should be changed to <nowiki>[[Category:Specifications]]</nowiki>.
;Participate
:<span id="issues">[https://github.com/microformats/microformats2-parsing/issues Open Issues]</span>
:[[microformats2-parsing-issues|Resolved issues before 2016-06-20]]
:[[IRC]]: [irc://irc.libera.chat/microformats #microformats on Libera]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
__TOC__
== algorithm ==
=== parse a document for microformats ===
To parse a document for microformats, follow the HTML parsing rules and do the following:
* start with an empty JSON "items" array and "rels" & "rel-urls" hashes:
<syntaxhighlight lang=javascript>
{
"items": [],
"rels": {},
"rel-urls": {}
}
</syntaxhighlight>
* parse the root element for class microformats, adding to the JSON items array accordingly
* parse all hyperlink (<code><a> <area> <link></code>) elements for rel microformats, adding to the JSON rels & rel-urls hashes accordingly
* return the resulting JSON
Parsers may simultaneously parse the document for both class and rel microformats (e.g. in a single tree traversal).

=== parse an element for class microformats ===
To parse an element for class microformats:
* parse element class for root class name(s) "h-*" and if none, backcompat root classes
** if none found, parse child elements for microformats (depth first, doc order)
** else if found, start parsing a new microformat
*** keep track of whether the root class name(s) was from backcompat
*** create a new { } structure with:
**** <code>type: <nowiki>[array of unique microformat "h-*" type(s) on the element sorted alphabetically]</nowiki>,</code>
**** <code>properties: { } </code> - to be filled in when that element itself is parsed for microformats properties
**** if the element has a non-empty <code>id</code> attribute:
***** <code>id:</code> string value of element's id attribute
*** parse child elements (document order) by:
**** if parsing a backcompat root, parse child element class name(s) for backcompat properties
**** else parse a child element class for property class name(s) "p-*,u-*,dt-*,e-*"
**** if such class(es) are found, it is a property element
***** add properties found to current microformat's <code>properties: { } </code> structure
**** parse a child element for microformats (recurse)
***** if that child element itself has a microformat ("h-*" or backcompat roots) and is a property element, add it into the array of values for that property as a { } structure, add to that { } structure:
****** <code>value</code>:
******* if it's a <code>p-*</code> property element, use the first p-name of the h-* child
******* else if it's an <code>e-*</code> property element, re-use its { } structure with existing <code>value:</code> inside.
******* else if it's a <code>u-*</code> property element and the h-* child has a u-url, use the first such u-url
******* else use the parsed property value per p-*,u-*,dt-* parsing respectively
***** else add found elements that are microformats to the "children" array
*** imply properties for the found microformat (see below)

The "*" for root (and property) class names consists of an optional vendor prefix (series of 1+ number or lowercase a-z characters i.e. <code>[0-9a-z]+</code>, followed by '-'), then one or more '-' separated lowercase a-z words.

=== parse an element for properties ===

==== parsing a <code>p-</code> property ====

To parse an element for a <code>p-x</code> property value (whether explicit <code>p-*</code> or backcompat equivalent):

* Parse the element for the [[value-class-pattern]]. If a value is found, return it.
* If <code>abbr.p-x[title]</code> or <code>link.p-x[title]</code>, return the <code>title</code> attribute.
* else if <code>data.p-x[value]</code> or <code>input.p-x[value]</code>, then return the <code>value</code> attribute
* else if <code>img.p-x[alt]</code> or <code>area.p-x[alt]</code>, then return the <code>alt</code> attribute
* else return the <code>textContent</code> of the element after:
** dropping any nested <code><script></code> & <code><style></code> elements;
** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present; otherwise their <code>src</code> attribute, if present, adding a space at the beginning and end, resolving the URL if it’s relative;
** removing all leading/trailing whitespace

==== parsing a <code>u-</code> property ====

To parse an element for a <code>u-x</code> property value (whether explicit <code>u-*</code> or backcompat equivalent):

* if <code>a.u-x[href]</code> or <code>area.u-x[href]</code> or <code>link.u-x[href]</code>, then get the <code>href</code> attribute
* else if <code>img.u-x[src]</code> return the result of "parse an img element for src and alt" (see Sec.1.5)
* else if <code>audio.u-x[src]</code> or <code>video.u-x[src]</code> or <code>source.u-x[src]</code> or <code>iframe.u-x[src]</code>, then get the <code>src</code> attribute
* else if <code>video.u-x[poster]</code>, then get the <code>poster</code> attribute
* else if <code>object.u-x[data]</code>, then get the <code>data</code> attribute
* else parse the element for the [[value-class-pattern]]. If a value is found, get it
* else if <code>abbr.u-x[title]</code>, then get the <code>title</code> attribute
* else if <code>data.u-x[value]</code> or <code>input.u-x[value]</code>, then get the <code>value</code> attribute
* else get the <code>textContent</code> of the element after removing all leading/trailing whitespace and nested <code><script></code> & <code><style></code> elements
* return the normalized absolute URL of the gotten value, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

==== parsing a <code>dt-</code> property ====

To parse an element for a <code>dt-x</code> property value (whether explicit <code>dt-*</code> or backcompat equivalent):

* parse the element for the [[value-class-pattern]], including the date and time parsing rules. If a value is found, then return it.
* if <code>time.dt-x[datetime]</code> or <code>ins.dt-x[datetime]</code> or <code>del.dt-x[datetime]</code>, then return the <code>datetime</code> attribute
* else if <code>abbr.dt-x[title]</code>, then return the <code>title</code> attribute
* else if <code>data.dt-x[value]</code> or <code>input.dt-x[value]</code>, then return the <code>value</code> attribute
* else return the <code>textContent</code> of the element after removing all leading/trailing whitespace and nested <code><script></code> & <code><style></code> elements.

==== parsing an <code>e-</code> property ====
To parse an element for a <code>e-x</code> property value (whether explicit "<code>e-*"</code> or backcompat equivalent):

* return a dictionary with two keys:
** <code>html</code>: the <code>innerHTML</code> of the element by using the [https://html.spec.whatwg.org/multipage/parsing.html#serialising-html-fragments HTML spec: Serializing HTML Fragments algorithm], with leading/trailing whitespace removed.
** <code>value</code>: the <code>textContent</code> of the element after:
*** dropping any nested <code><script></code> & <code><style></code> elements;
*** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present; otherwise their <code>src</code> attribute, if present, adding a space at the beginning and end, resolving the URL if it’s relative;
*** removing all leading/trailing whitespace

==== parsing for implied properties ====

Imply properties only on explicit <code>h-x</code> class name root microformat element (no backcompat roots):

* if no explicit "<code>name</code>" property, and no other <code>p-*</code> or <code>e-*</code> properties, and no nested microformats,
* then imply by:
** if <code>img.h-x</code> or <code>area.h-x</code>, then use its <code>alt</code> attribute for name
** else if <code>abbr.h-x[title]</code> then use its <code>title</code> attribute for name
** else if <code>.h-x>img:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>img</code>’s <code>alt</code> for name
** else if <code>.h-x>area:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>area</code>’s <code>alt</code> for name
** else if <code>.h-x>abbr:only-child[title]:not([title=""]):not[.h-*]</code> then use that <code>abbr</code> <code>title</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>img:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>img</code>’s <code>alt</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>area:only-child[alt]:not([alt=""]):not[.h-*]</code> then use that <code>area</code>’s <code>alt</code> for name
** else if <code>.h-x>:only-child:not[.h-*]>abbr:only-child[title]:not([title=""]):not[.h-*]</code> use that <code>abbr</code>’s <code>title</code> for name
** else use the <code>textContent</code> of the <code>.h-x</code> for <code>name</code> after:
*** dropping any nested <code><script></code> & <code><style></code> elements;
*** replacing any nested <code><img></code> elements with their <code>alt</code> attribute, if present;
** remove all leading/trailing whitespace
* if no explicit "<code>photo</code>" property, and no other explicit <code>u-*</code> properties, and no nested microformats,
* then imply by:
** if <code>img.h-x[src]</code>, then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>object.h-x[data]</code> then use <code>data</code> for photo
** else if <code>.h-x>img[src]:only-of-type:not[.h-*]</code> then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>.h-x>object[data]:only-of-type:not[.h-*]</code> then use that <code>object</code>’s <code>data</code> for photo
** else if <code>.h-x>:only-child:not[.h-*]>img[src]:only-of-type:not[.h-*]</code>, then use the result of "parse an img element for src and alt" (see Sec.1.5) for photo
** else if <code>.h-x>:only-child:not[.h-*]>object[data]:only-of-type:not[.h-*]</code>, then use that <code>object</code>’s <code>data</code> for photo
** if there is a gotten photo value, return the normalized absolute URL of it, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).
* if no explicit "<code>url</code>" property, and no other explicit <code>u-*</code> properties, and no nested microformats,
* then imply by:
** if <code>a.h-x[href]</code> or <code>area.h-x[href]</code> then use that <code>[href]</code> for url
** else if <code>.h-x>a[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>area[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>:only-child:not[.h-*]>a[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** else if <code>.h-x>:only-child:not[.h-*]>area[href]:only-of-type:not[.h-*]</code>, then use that <code>[href]</code> for url
** if there is a gotten url value, return the normalized absolute URL of it, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

<strong>Note:</strong> The same markup for a property should not be causing that property to occur in <em>both</em> a microformat and one embedded inside - such a property should only be showing up on one of them. The parsing algorithm has details to prevent that, such as the <code>:not[.h-*]</code> tests above.

=== parse a hyperlink element for rel microformats ===
To parse a hyperlink element (e.g. a or link) for rel microformats: use the following algorithm or an algorithm that produces equivalent results:
* if the "rel" attribute of the element is empty then exit
* set url to the value of the "href" attribute of the element, normalized to be an absolute URL following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element if any).
* treat the "rel" attribute of the element as a space separate set of rel values
* for each rel value (rel-value)
** if there is no key rel-value in the rels hash then create it with an empty array as its value
** if url is not in the array of the key rel-value in the rels hash then add url to the array
* end for
* if there is no key with name url in the top-level "rel-urls" hash then add a key with name url there, with an empty hash value
* add keys to the hash of the key with name url for each of these attributes (if present) and key not already set:
** "hreflang": the value of the "hreflang" attribute
** "media": the value of the "media" attribute
** "title": the value of the "title" attribute
** "type": the value of the "type" attribute
** "text": the text content of the element if any
* if there is no "rels" key in that hash, add it with an empty array value
* set the value of that "rels" key to an array of all unique items in the set of rel values unioned with the current array value of the "rels" key, sorted alphabetically.

==== rel parse examples ====
Here are some examples to show how parsed rels may be reflected into the JSON (empty items key).

E.g. parsing this markup:
<syntaxhighlight lang=xml>
<a rel="author" href="http://example.com/a">author a</a>
<a rel="author" href="http://example.com/b">author b</a>
<a rel="in-reply-to" href="http://example.com/1">post 1</a>
<a rel="in-reply-to" href="http://example.com/2">post 2</a>
<a rel="alternate home"
href="http://example.com/fr"
media="handheld"
hreflang="fr">French mobile homepage</a>
</syntaxhighlight>

Would generate this JSON:
<syntaxhighlight lang=javascript>
{
"items": [],
"rels": {
"author": [ "http://example.com/a", "http://example.com/b" ],
"in-reply-to": [ "http://example.com/1", "http://example.com/2" ],
"alternate": [ "http://example.com/fr" ],
"home": [ "http://example.com/fr" ]
},
"rel-urls": {
"http://example.com/a": {
"rels": ["author"],
"text": "author a"
},
"http://example.com/b": {
"rels": ["author"],
"text": "author b"
},
"http://example.com/1": {
"rels": ["in-reply-to"],
"text": "post 1"
},
"http://example.com/2": {
"rels": ["in-reply-to"],
"text": "post 2"
},
"http://example.com/fr": {
"rels": ["alternate", "home"],
"media": "handheld",
"hreflang": "fr",
"text": "French mobile homepage"
}
}
}
</syntaxhighlight>

=== parse an img element for src and alt ===
To parse an <code>img</code> element for <code>src</code> and <code>alt</code> attributes:
* if <code>img[alt]</code>
** return a new <code>{}</code> structure with
*** <code>value</code>: the element's <code>src</code> attribute as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).
*** <code>alt</code>: the element's <code>alt</code> attribute
* else
** return the element's <code>src</code> attribute as a normalized absolute URL, following the containing document's language's rules for resolving relative URLs (e.g. in HTML, use the current URL context as determined by the page, and first <code><base></code> element, if any).

== what do the CSS selector expressions mean ==
''This section is non-normative.''

Use [http://gallery.theopalgroup.com/selectoracle/ SelectORacle] to expand any of the above CSS selector expressions into longform English prose.

Exception:
* ''':not[.h-*]''' is not a valid CSS selector but is used here to mean:
** does not have any class names that start with "h-"

== note HTML parsing rules ==
''This section is non-normative.''

microformats2 parsers are expected to follow HTML parsing rules, which includes for example:
* ignore <code><template></code> elements - stuff between <code><template></code> tags don't end up in the DOM
** test-case in the wild: http://sixtwothree.org/blog/now-accepting-webmentions/

== note backward compatibility details ==
The parsing algorithm and details refer to "backcompat root classes" (backcompat roots for short) and "backcompat properties". These conditions and steps in the algorithm document how to parse pre-microformats2 microformats which all defined their own specific root class names and explicit sets of properties.

Some details to be aware of (which are explicitly in the algorithm, this is just an informal summary)
* If an element has one or more microformats2 root class name(s) (<code>h-*</code>)
** all backcompat root class names are ignored on that element.
** all backcompat properties, without an intervening root class name, are ignored inside that element
* If an element has only a backcompat root class name (or names)
** all microformats2 property class names (p-* u-* dt-* e-*), without an intervening element with root class name, are ignored inside that element
** there is no implied property value parsing (p-name, u-url, u-photo) for that element

=== backward compatibility mappings ===
Note: several parser implementations have encoded backward compatible mappings into source and data files. Implementers of parsers may find these useful:
* search for "modules.maps[" in https://github.com/glennjones/microformat-shiv/blob/master/microformat-shiv.js
* search for "$classicPropertyMap" in https://github.com/indieweb/php-mf2/blob/master/Mf2/Parser.php
* https://github.com/tommorris/mf2py/blob/master/mf2py/backcompat.py

== questions ==
See the FAQ:
* [[microformats2-parsing-faq]]

== implementations ==
{{main|microformats2#Implementations}}
There are open source [[microformats2#Implementations|microformats2 parsers]] available for Javascript, node.js, PHP, Ruby and Python.

== test suite ==
See:
* https://github.com/microformats/tests
* https://github.com/indieweb/php-mf2/tree/master/tests/Mf2

Ports to/for other languages encouraged.

== change control ==
Minor editorial changes (e.g. fixing minor typos or punctuation) that do not change and preferably clarify the structure and existing intended meaning may be done by anyone without filing issues, requiring only a sufficient "Summary" description field entry for the edit. More than minor but still purely editorial changes may be made by an editor. Anyone may question such editorial changes by undoing corresponding edits without filing an issue. Any further reversion or iteration on such an editorial change must be done by filing an issue.

Per the stable status of this document, substantive issue filing, resolution, and edits are done with the following change control steps, which may nearly all be done asynchronously once an issue is filed to reach the required state of "Resolve by implementation verified rough consensus". All steps should be openly documented (e.g. on this wiki or GitHub issues) such that others may later verify the history of an issue, and all steps are encouraged to be announced on #microformats [[IRC]] with a link to the issue.

* '''File an issue.''' Anyone may file a new [[microformats2-parsing-issues|issue]] and is encouraged to do so, with the caveat that per the stable status, only issues originating as a result of implementation experience are likely to have a substantive impact on this specification.
* '''Propose a resolution.''' Anyone may propose resolutions to existing issues, and should encourage others in the community, especially implementers, to provide feedback. Proposed resolutions should include what specific text of the spec needs changing, preferably with replacement text, and test cases if applicable (e.g. a resolution could just document the current state more precisely without needing to provide any new test cases).
* '''Provide feedback on proposed resolution(s).''' Anyone may provide feedback on proposed resolutions with their name attached, in summary (e.g. +1/0/-1 opinions), and additionally with reasoning (required for objections, optional otherwise), or optionally with suggested improvements, or counter-proposals (per "Propose a resolution" above).
* '''Iterate to resolve objections if any.''' If there are any objections to a proposed resolution, proposer(s) and anyone agreeing should work to iterate on the proposal to resolve objections to the satisfaction (or at least withdrawal of objection) of anyone objecting. The more objections resolved the better, and incremental progress is forward progress.
* '''Broaden implementer consensus.''' Proposer(s) and anyone agreeing should reach out (e.g. via #microformats [[IRC]]) to multiple implementers of the specification to get their opinions and feedback on proposal(s). The more implementers providing feedback the better. Iterate to resolve any new objections per "Iterate to resolve objections if any" above.
* '''Encourage and get 1+ implementation(s).''' Encourage, get, and document 1+ implementation(s) of implementation affecting aspects of a proposed resolution, preferably with a test case if applicable.
* '''Resolve by implementation verified rough consensus.''' Once there is rough consensus on a proposal (where <dfn>rough consensus</dfn> means <strong>either no objections, or at a minimum no objections by implementers, and explicit positive opinions by 2+ implementers</strong>) and a proposal's feasibility is verified by at least 1 implementation of aspects of the proposal that affect implementations (none needed if there are none, e.g. purely editorial), cite those in a "Resolution:" statement on the issue (e.g. in a comment), and explicitly share this resolution statement and link to issue in the #microformats [[IRC]] channel.
* '''Edit specification.''' Normally the spec editor(s) will make edits per implementation verified rough consensus resolutions, however anyone (though especially issue discussion participants) may make a specification edit per a resolution if they are able to verify the citations that the resolution has achieve rough consensus, and has 1+ implementation(s) per "Encourage and get 1+ implementation(s)" above. Edits must contain a "Summary" field entry that at a minimum mention the issue by name, should provide a URL to the issue resolution, and preferably be done by a spec editor or an implementer. Once the edit is made, the issue should be closed, or at least a comment made on the issue requesting that the opener of the issue close the issue.

These change control steps are inspired by the tradition of "Rough consensus and running code" as exhibited by example by IETF and W3C processes, and in that regard, seek to be a philosophically compatible approach to specification iteration. They have been in rough practice since 2015-01-21, increasingly strictly applied since then with consensus of issue discussion participants, and explicitly documented based on issue resolving and spec editing experience.

== see also ==
* [[microformats2]]
* [[microformats2-parsing-faq]]
* [[microformats2-parsing-issues]]
* [[microformats2-parsing-brainstorming]] - for background, thinking, exploring possibilities
* [[microformats2-parsing-rdf]]
* [[microformats2-implied-properties]]

[[Category:Draft Specifications]]

h-card

2022-11-30T23:42:04Z

Btrem: Fix: replaces deprecated <source> tag with <syntaxhighlight>

<dfn style="font-style:normal;font-weight:bold">h-card</dfn> is a simple, open format for publishing people and organisations on the web. h-card is often used on home pages and individual blog posts. h-card is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-card is the [[microformats2]] update to [[hCard]].

;<span id="status">Status</span>
:This is a '''Living Specification''' yet mature enough to encourage additional implementations and [https://github.com/microformats/h-card/issues feedback].
;<span id="participate">Participate</span>
:[https://github.com/microformats/h-card/issues Open Issues]
:[[IRC]]
<div class="p-author h-card vcard">
;<span class="p-role role">Editor</span>
:<span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span>
</div>
;License
: {{cc0-owfa-license}}
<span style="float:right">__TOC__</span>

== Example ==
Here are a couple of minimal examples:

<syntaxhighlight lang=html>
<a class="h-card" href="https://tantek.com/">Tantek Çelik</a>,

<span class="h-card">
<a class="p-name p-org u-url" href="https://microformats.org/">microformats.org</a>
</span>
</syntaxhighlight>

Parsed JSON:
<syntaxhighlight lang=javascript>
{
"items": [
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://tantek.com/"]
}
},
{
"type": ["h-card"],
"properties": {
"name": ["microformats.org"],
"org": ["microformats.org"],
"url": ["https://microformats.org/"]
}
}
]
}
</syntaxhighlight>
Note a single element was sufficient for the simple person example with implied name and URL properties, while for an organization, which requires a name and org, it needed explicit markup for the h-card and all properties, though still with only two elements.

Nested h-card example:

<syntaxhighlight lang=html>
<div class="h-card">
<a class="p-name u-url"
href="https://blog.lizardwrangler.com/"
>Mitchell Baker</a>
(<a class="p-org h-card"
href="https://mozilla.org/"
>Mozilla Foundation</a>)
</div>
</syntaxhighlight>

Parsed JSON:
<syntaxhighlight lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Mitchell Baker"],
"url": ["https://blog.lizardwrangler.com/"],
"org": [{
"value": "Mozilla Foundation",
"type": ["h-card"],
"properties": {
"name": ["Mozilla Foundation"],
"url": ["https://mozilla.org/"]
}
}]
}
}]
}
</syntaxhighlight>

Note: the nested h-card has implied 'name' and 'url' properties, just like any other root-class-name-only h-card on an <code><a href></code> would.

=== Get started ===
The class '''<code>h-card</code>''' is a ''root class name'' that indicates the presence of an h-card.

For minimal examples where at most <code>p-name</code>, <code>u-url</code> and <code>u-photo</code> are required (such as the first given above), only the root class name is needed — see [[microformats-2-implied-properties|implied properties]].

When more than those three minimal properties are needed, the root class name must be placed on an element which encloses all the desired properties, and then the properties themselves marked up using the classnames given below.

See [[microformats2-parsing]] to learn more about property classnames.

== Properties ==
h-card properties, inside an element with class '''h-card'''. All properties are optional and may be plural.
* See [[microformats2-parsing]] to learn more about property classnames.

<div style="margin-top:-.4em; float:right;"><span>Example h-card with common properties:</span>
<ul style="list-style:none"><li><code><div class="'''h-card'''"></code>
<ul style="list-style:none; margin-top:-.02em">
<li><code><span class="'''p-name'''">Sally Ride</span></code></li>
<li><code><span class="'''p-honorific-prefix'''">Dr.</span></code></li>
<li><code><span class="'''p-given-name'''">Sally</span></code></li>
<li><code><abbr class="'''p-additional-name'''">K.</abbr></code></li>
<li><code><span class="'''p-family-name'''">Ride</span></code></li>
<li><code><span class="'''p-honorific-suffix'''">Ph.D.</span>,</code></li>
<li><code><span class="'''p-nickname'''">sallykride</span> (IRC)</code></li>
<li><code><div class="'''p-org'''">Sally Ride Science</div></code></li>
<li><code><img class="'''u-photo'''" src="<nowiki>http://example.com/sk.jpg</nowiki>"/> </code></li>
<li><code><a class="'''u-url'''" href="<nowiki>http://sally.example.com</nowiki>">w</a>,</code></li>
<li><code><a class="'''u-email'''" href="<nowiki>mailto:sally@example.com</nowiki>">e</a> </code></li>
<li><code><div class="'''p-tel'''">+1.818.555.1212</div></code></li>
<li><code><div class="'''p-street-address'''">123 Main st.</div></code></li>
<li><code><span class="'''p-locality'''">Los Angeles</span>, </code></li>
<li><code><abbr class="'''p-region'''" title="California">CA</abbr>, </code></li>
<li><code><span class="'''p-postal-code'''">91316</span></code></li>
<li><code><div class="'''p-country-name'''">U.S.A</div></code></li>
<li><code><time class="'''dt-bday'''">1951-05-26</time> birthday</code></li>
<li><code><div class="'''p-category'''">physicist</div></code></li>
<li><code><div class="'''p-note'''">First American woman in space.</div></code></li></ul></li>
<li><code></div></code></li></ul>
</div>
Core properties:
* '''<code>p-name</code>''' - The full/formatted name of the person or organization
* '''<code>p-honorific-prefix</code>''' - e.g. Mrs., Mr. or Dr.
* '''<code>p-given-name</code>''' - given (often first) name
* '''<code>p-additional-name</code>''' - other (e.g. middle) name
* '''<code>p-family-name</code>''' - family (often last) name
* '''<code>p-sort-string</code>''' - string to sort by
* '''<code>p-honorific-suffix</code>''' - e.g. Ph.D, Esq.
* '''<code>p-nickname</code>''' - nickname/alias/handle
* '''<code>u-email</code>''' - email address
* '''<code>u-logo</code>''' - a logo representing the person or organization (e.g. a face icon)
* '''<code>u-photo</code>''' - a photo of the person or organization
* '''<code>u-url</code>''' - home page or other URL representing the person or organization
* '''<code>u-uid</code>''' - universally unique identifier, preferably canonical URL
* '''<code>p-category</code>''' - category/tag
* '''<code>p-adr</code>''' - postal address, optionally embed an [[h-adr]] {{main|h-adr}}
* '''<code>p-post-office-box</code>''' - post office box description if any
* '''<code>p-extended-address</code>''' - apartment/suite/room name/number if any
* '''<code>p-street-address</code>''' - street number + name
* '''<code>p-locality</code>''' - city/town/village
* '''<code>p-region</code>''' - state/county/province
* '''<code>p-postal-code</code>''' - postal code, e.g. US ZIP
* '''<code>p-country-name</code>''' - country name
* '''<code>p-label</code>'''
* '''<code>p-geo</code>''' or '''<code>u-geo</code>''', optionally embed an [[h-geo]] {{main|h-geo}}
* '''<code>p-latitude</code>''' - decimal latitude
* '''<code>p-longitude</code>''' - decimal longitude
* '''<code>p-altitude</code>''' - decimal altitude
* '''<code>p-tel</code>''' - telephone number
* '''<code>p-note</code>''' - additional notes
* '''<code>dt-bday</code>''' - birth date
* '''<code>u-key</code>''' - cryptographic public key e.g. SSH or GPG
* '''<code>p-org</code>''' - affiliated organization, optionally embed an [[h-card]]
* '''<code>p-job-title</code>''' - job title, previously 'title' in [[hCard]], disambiguated.
* '''<code>p-role</code>''' - description of role
* '''<code>u-impp</code>''' per RFC4770, new in vCard4 (RFC 6350)
* '''<code>p-sex</code>''' - biological sex, new in vCard4 (RFC 6350)
* '''<code>p-gender-identity</code>''' - gender identity, new in vCard4 (RFC 6350)
* '''<code>dt-anniversary</code>'''

Experimental properties currently in use in the wild but not (yet) part of the official h-card spec.

* '''<code>u-sound</code>''' - sound file containing the proper pronunciation of the name property, per vCard (RFC 6350).
** Used by [https://vanderven.se/martijn/ Martijn van der Ven] with a clip of his given name.
** Needs a GitHub issue to track.

== Status ==
'''h-card''' is a microformats.org draft specification. Public discussion on h-card takes place on the [[irc|#microformats channel on irc.freenode.net]] ([https://chat.indieweb.org/microformats view recent discussions]), and specific issues [https://github.com/microformats/h-card/issues may be filed on GitHub].

h-card is ready to use and implemented in the wild. For backwards compatibility you should also mark up top-level h-cards as classic [[hCard]]s.

== Property Details ==
(stub, to be expanded)

=== p-adr ===
<code>p-adr</code> can optionally embed an [[h-adr]] to cluster associated structured address properties. E.g. adding "p-adr" to the example earlier:

<syntaxhighlight lang=html>
<div class="h-card">
<p class="p-name">Joe Bloggs</p>
<p class="p-adr h-adr">
<span class="p-street-address">17 Austerstræti</span>
<span class="p-locality">Reykjavík</span>
<span class="p-country-name">Iceland</span>
</p>
</div>
</syntaxhighlight>

Q: Why would you use "p-adr" to cluster associated structured address properties?

A: Because if you have more than one structured address, clustering which properties go with which address keeps them deterministically together, instead of depending on array indices or other heuristics.

=== p-tel ===
Note: use of 'value' within 'p-tel' should be automatically handled by the support of the [[value-class-pattern]]. And for now, the former [[hCard]] 'type' subproperty of 'tel' is dropped/ignored. If there is demonstrable documented need for additional tel types (e.g. fax), we can introduce new flat properties as needed (e.g. p-tel-fax).

=== dt-bday ===
Using truncated representations of dates for birth date is often good practice as noted in [https://tools.ietf.org/html/rfc6350#section-4.3.1 the vcard spec] eg
* <code>1985-04</code> for April 1985
* <code>1985</code> for the year 1985
* <code>--04-12</code> for April 12th with no specified year

=== Reserved properties ===
The following properties were supported by the legacy hCard format, but were not carried over to h-card due to lack of real-world usage, or other problems. They are not part of h-card and should not be published, consumed, or proposed.

* '''<code>p-organization-name</code>'''
* '''<code>p-organization-unit</code>'''
* '''<code>p-tz</code>''' — timezone offset
** <q>it's going to be a hard one to "get right", as the way timezones work in vcard/ical is very weird, and timezones as a whole are an iffy thing to denote (quite the disconnect between complexity, automated processing ability, actually representing what a user would want to show/display or already does on their homepage, and actually representing something useful to parse and do something with)</q>
** <q>there's certainly no ecosystem of publishers & consumers supporting p-tz in any meaningful interoperable way</q> — [https://chat.indieweb.org/microformats/2021-06-22/1624385751126500 tantek in #microformats]
* '''<code>dt-rev</code>'''

== Examples in the wild ==
See also: [https://indieweb.org/h-card#IndieWeb_Examples h-card Examples on indieweb.org]

Real world in the wild examples of sites and services that publish or consume h-card:

* ... add uses of h-card you see in the wild here.
* [http://www.securityjobslondon.co.uk Security Jobs London] uses h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) in the footer of each page
* Brett Comnes marks up his posts with h-card ([http://bret.io/2013/06/29/getting-started-with-bower/ example])
* Ben Werdmuller marks up his homepage and posts with h-card [http://werd.io/view/51d5097fbed7ded0633a5956 example])
* [https://joelpurra.com/ Joel Purra] uses a hidden h-card with legacy [[hCard]] fallback markup (to satisfy [https://search.google.com/structured-data/testing-tool Google's Structured Data Testing Tool]) on the front page
* [http://eschnou.com/ Laurent Eschenauer] marks his homepage profile up using h-card
* [http://tommorris.org/ Tom Morris] marks himself up with h-card as well as venues he’s checked into ([http://tommorris.org/posts/8408 example])
* [https://www.w3.org/conf/ W3Conf 2013] uses h-card for all the event speakers and notable attendees. The h-cards make particularly good use of implied name, url, and photo properties.
* [http://wordpress.org/extend/themes/sempress SemPress] is a WordPress theme that supports h-card, h-feed/h-entry and h-as-*
* [http://the-pastry-box-project.net/ The Pastry Box Project] use h-card markup on their homepage and individual thoughts pages
* Tom Morris uses h-card and [[XFN]] to markup [http://tommorris.org/pages/blogroll his blogroll].
* Aaron Parecki uses h-card to markup both authorship and references to people in his notes permalinks, e.g. [https://aaronparecki.com/2012/230/reply/1 2012/230/reply/1].
* [https://tantek.com/ Tantek Çelik] uses h-card on his home page as well as within [[h-entry]]s on permalink pages to indicate authorship.
* [http://waterpigs.co.uk/ Barnaby Walters] uses h-card on his home page, as well as within h-entries for notes and articles, both to indicate authorship and also when mentioning people within the body of the notes.
* [https://tantek.com/presentations/2012/06/microformats microformats.org at 7 years] presentation with and h-card markup for people and organizations.
* [https://tantek.com/presentations/2012/06/pdf2012-indieweb.html Rise of the Indie Web hCards] (from Personal Democracy Forum 2012 #pdf12 #pdf2012) has [[microformats2]] h-card markup
* WebMaker by Mozilla has [[microformats2]] h-card on event search (e.g. [https://webmaker.org/en-US/events/near/?lat=45.5234515&lng=-122.6762071 search near Portland Oregon]) and event pages (e.g. [https://webmaker.org/en-US/events/192f56eb9/ IndieWebCamp 2012]).[https://twitter.com/microformats/status/212207925643587585]
* WebFWD by Mozilla has [[microformats2]] h-card markup on [https://webfwd.org/about/experts/ experts] and [https://webfwd.org/about/team/ team] pages
* [https://indiewebcamp.com IndieWebCamp] has [[microformats2]] h-event markup with embedded h-cards for the organizers and the location.
* [https://wiki.mozilla.org/Events Mozilla Events] page has [[microformats2]] h-event markup with attendees marked up with h-card.
* [https://tristanthomas.me Tristan Thomas] uses h-card on his home page
* [http://cold32.com/about-the-author-and-contact.htm Cold32.com] uses h-card (and h-geo) on its about-the-author-and-contact page
* [https://workfrom.co/ Workfrom.co] renders h-cards for venues (e.g. [https://workfrom.co/palio-dessert-and-espresso-house])
* [http://www.pcwdld.com/ PCWDLD.com] renders h-cards for download pages(e.g. [http://www.pcwdld.com/solarwinds-network-topology-mapper-review Download page example])

=== offline ===
* spreadly marks up share permalink pages with minimal h-cards inside h-entry
* App.net rolled out support for h-card and h-entry on all profile pages and permalink pages as of 2013-08-06 ([https://alpha.app.net/voidfiles example])
* Sandeep Shetty marks his homepage and posts up with h-card and h-entry ([https://sandeep.io/101 example])

== Validating ==
* '''[https://indiewebify.me/validate-h-card/ indiewebify.me h-card validator]''' parses [[h-card]] markup and makes suggestions for things to add, with code samples
{{h-spec-section-validating}}

== Implementations ==
Software implementations that publish or consume h-card, including themes, plugins, or extensions:

(This section is a stub that needs expansion! In practice, nearly every CMS on every [https://indieweb.org/ indie web] site supports publishing h-card by default, and most sites which support receiving webmentions parse h-card for authorship data.)

When adding an implementation, please provide and link to its home page and open source repo if any.
* [https://gnu.io/social/ GNUsocial] [https://git.gnu.io/gnu/gnu-social/ source code]
* [https://hubzilla.org/hubzilla/ Hubzilla] [https://github.org/redmatrix/hubzilla source code]
* [http://friendica.com/ Friendica] [https://github.org/friendica/friendica source code]
* [https://github.com/dissolve/inkblot InkBlot]
* [https://aperture.p3k.io/ Aperture] consumes h-card to show authorship information of feed posts ([https://github.com/aaronpk/Aperture/ source code])
* [https://xray.p3k.app/ XRay] consumes h-card and flattens it into a more minimal format ([https://github.com/aaronpk/XRay/ source code])
* [https://withknown.com/ Known] publishes and consumes h-card to show authorship of posts and responses
* [https://brid.gy/ Bridgy] publishes microformats-2 versions of siloed content (including h-card for authorship) for consumption by mf2-consumers
* [https://webmention.io/ webmention.io] consumes h-card for authorship data of incoming webmentions which it accepts on behalf of other sites
* ...
* ...

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hCard]] classnames in addition to the more future-proof h-card properties, for example:

<syntaxhighlight lang=html>
<p class="h-card vcard">
<span class="p-name fn">Joe Bloggs</span>,
<span class="p-org org">Awesome Nonprofit</span>
...
</p>
</syntaxhighlight>

The class '''<code>vcard</code>''' is a ''backward compatible root class name'' that indicates the presence of an [[hCard]].

'''fn''', '''org''', and all the other backward compatibility hCard property class names are listed below.

=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-card" is found, don't look for a "vcard" on the same element.

Compat. root class name: <code id="vcard">vcard</code><br/>
Properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>honorific-prefix</code>
* <code>given-name</code>
* <code>additional-name</code>
* <code>family-name</code>
* <code>honorific-suffix</code>
* <code>nickname</code>
* <code>email</code> - parse as '''u-'''
* <code>logo</code> - parse as '''u-'''
* <code>photo</code> - parse as '''u-'''
* <code>url</code> - parse as '''u-'''
* <code>uid</code> - parse as '''u-'''
* <code>category</code>
* <code>adr</code> - parse as '''<code>p-adr h-adr</code>''' including compat root class <code>adr</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>
* <code>label</code>
* <code>geo</code> - parse as '''<code>p-geo h-geo</code>''' including compat root class <code>geo</code>
* <code>latitude</code>
* <code>longitude</code>
* <code>tel</code>
* <code>note</code>
* <code>bday</code> - parse as '''dt-'''
* <code>key</code> - parse as '''u-'''
* <code>org</code>
* <code>organization-name</code>
* <code>organization-unit</code>
* <code>title</code> - parse as '''p-job-title'''
* <code>role</code>

Reserved: (backward compat properties that parsers {{may}} implement, if they do, they {{must}} implement in this way:
* <code>tz</code>
* <code>rev</code> - parse as '''dt-'''

== Background ==
This work is based on the existing [[hCard]] and [[vcard]] specifications.

== Design Principles ==

(stub, expand)

== Additions ==
We've tried very hard with h-card to stay compatible with the vCard4 vocabulary, and thus additions should be proposed on the vCard4 mailing list.

However, you may still use this wiki to capture additions for h-card here:
* [[h-card-brainstorming]]

== See Also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[h-adr]]
* [[h-geo]]
* [[hCard]]

[[Category:Draft Specifications]]

svg

2022-11-30T23:34:53Z

Btrem: Fix: replaces deprecated <source> tag with <syntaxhighlight>

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Example ==

Here is a simple example:

<syntaxhighlight lang=html>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text class="p-name" x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</syntaxhighlight>

== See also ==

* https://btrem.com/2021/04-svg-microformats

svg

2022-11-30T22:40:03Z

Btrem: Adds simple example of microformats in svg.

{{stub}}

The [https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/class class attribute is allowed on SVG elements]. As such, there are rich possibilities for embedding microformats with or in them.

== Example ==

Here is a simple example:

<source lang=html>
<svg class="h-card" viewBox="0 0 200 200" height="200" width="200">
<circle cx="50%" cy="50%" r="100" fill="gold"/>
<text class="p-name" x="25" y="110" font-size="30">
Example Co.
</text>
</svg>
</source>

== See also ==

* https://btrem.com/2021/04-svg-microformats

h-recipe

2022-11-29T23:32:40Z

Btrem: /* Core Properties */ spelling correction

{{DISPLAYTITLE:h-recipe}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-recipe</dfn> is a simple, open format for publishing recipes on the web. h-recipe is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-recipe is the [[microformats2]] update to [[hRecipe]].

{{cc0-owfa-license}}

== Example ==
Here is a simple minimal recipe example:

<source lang=html4strict>
<article class="h-recipe">
<h1 class="p-name">Bagels</h1>

<ul>
<li class="p-ingredient">Flour</li>
<li class="p-ingredient">Sugar</li>
<li class="p-ingredient">Yeast</li>
</ul>

<p>Takes <time class="dt-duration" datetime="1H">1 hour</time>,
serves <data class="p-yield" value="4">four people</data>.</p>

<div class="e-instructions">
<ol>
<li>Start by mixing all the ingredients together.</li>
</ol>
</div>
</article>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-recipe"
],
"properties": {
"name": [
"Bagels"
],
"ingredient": [
"Flour",
"Sugar",
"Yeast"
],
"yield": [
"4"
],
"instructions": [
{
"value": "Start by mixing all the ingredients together.",
"html": "<ol> <li>Start by mixing all the ingredients together.</li> </ol>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-recipe</code>''' is a ''root class name'' that indicates the presence of an h-recipe.

'''p-name''', '''e-instructions''', '''p-ingredient''' and the other property classnames listed below define elements as ''properties'' of the h-recipe.

See [[microformats-2-parsing]] to learn more about property classnames.

== Properties ==

=== Core Properties ===

The following core h-entry properties have broad consensus and are broadly interoperably published and consumed:

h-recipe properties, inside an element with class '''h-recipe''':

* '''<code>p-name</code>''' - the name of the recipe
* '''<code>p-ingredient</code>''' - describes one or more ingredients used in the recipe.
* '''<code>p-yield</code>''' - Specifies the quantity produced by the recipe, like how many persons it satisfies
* '''<code>e-instructions</code>''' - the method of the recipe.
* '''<code>dt-duration</code>''' - the time it takes to prepare the meal described by the recipe.
* '''<code>u-photo</code>''' - an accompanying image

=== Experimental properties with wide adoption ===
* '''<code>p-summary</code>''' - provides a short summary or introduction
* '''<code>p-author</code>''' - person who wrote the recipe, optionally embedded with <code>h-card</code> {{main|h-card}}
* '''<code>dt-published</code>''' - the date the recipe was published
* '''<code>p-nutrition</code>''' - nutritional information like calories, fat, dietary fiber etc.
* '''<code>p-category</code>''' - recipe categories/tags
* ...

=== Proposed properties ===

The following properties are proposed additions based on various use-cases but are awaiting citations of use across multiple sites in the wild, and at least one reader / real world consuming code example:

* '''<code id="u-remix-of">u-remix-of</code>''' - the URL which the h-entry is considered a “remix” of. Optionally an embedded [[h-cite]]. The purpose of this in an h-recipe is to identify that this recipe is a remix, or based on another recipe, and giving appropriate citation to that individual. In theory, if this was an exact copy, the u-repost-of used in h-entry would apply.

== Status ==

'''h-recipe''' is a microformats.org draft specification. Public discussion on h-recipe takes place on [[h-recipe-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-recipe is ready to use and implemented in the wild, but for backwards compatibility you should also mark h-recipes up with classic [[hRecipe]] classnames.

== Property Details ==

(stub, add any property explanations here)

'''dt-duration''' should be marked up using the [http://developers.whatwg.org/common-microsyntaxes.html#durations duration] microsyntax defined in HTML5. TODO: add more examples

[[hRecipe]] has a number of experimental properties which have real world adoption due to [[Google]] recipe search support of hRecipe. These are: summary, author, published and nutrition.

== Examples in the Wild ==
* [http://www.eliduke.com Eli Duke] has posted some h-[http://www.eliduke.com/recipes recipes] on his site:
** http://www.eliduke.com/recipes/kale-salad
** http://www.eliduke.com/recipes/hummus
** http://www.eliduke.com/recipes/wacky-cake
** http://www.eliduke.com/recipes/vegan-mac-and-cheese

* [https://cleverdevil.io Jonathan LaCour] has created several h-[http://cleverdevil.io/content/recipes recipes] using his Known plugin on his site:
** https://cleverdevil.io/2015/kentucky-maid-cocktail

* [https://makeitperfectly.com Perfect Company] marks up their recipes with h-recipe:
** https://makeitperfectly.com/drink/recipes/1a1913f6-6ba2-11e5-a3ed-f372faffcfa4
** https://makeitperfectly.com/bake/recipes/194a6cea-6ba2-11e5-a3ed-8367b69ac326

* [https://aaronparecki.com/recipes Aaron Parecki] has several recipes on his website
** https://aaronparecki.com/2020/06/01/19/banana-bread
** https://aaronparecki.com/2018/12/25/8/habanero-sauce

== Validating ==
{{h-spec-section-validating}}

== Implementations ==
This section is '''informative'''.

Tools for generating and consuming h-recipe. When it gets too big we can move it to a separate page like [[h-recipe-implementations]].

Consuming h-recipe (sites and tools that consume and do something with h-recipe)
* [https://developers.pinterest.com/docs/rich-pins/recipes/ Pinterest] supports h-recipe to create "rich pins"
* ... (stub)

Generating h-recipe (sites and tools that help produce and publish h-recipe)
* [https://github.com/cleverdevil/Known-Recipes Recipe post generator for Known CMS] by [https://cleverdevil.io Jonathan LaCour].

Advocacy - open source and other implementations which would benefit from h-recipe support or some degree of support has been requested - feel free to help implement these.
* OpenRecipes [https://github.com/fictivekin/openrecipes/issues/198 issue 198] feature request: update spider to parse for the original hRecipe microformat, and the new h-recipe microformats2 update

== Backward Compatibility ==
=== Publisher Compatibility ===
(stub)
=== Parser Compatibility ===
Microformats parsers {{should}} detect classic properties only if a classic root class name is found and parse them as microformats2 properties.

If an "h-recipe" is found, don't look for an "hrecipe" on the same element.

compat root class name: <code id="hrecipe">hrecipe</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>ingredient</code>
* <code>yield</code>
* <code>instructions</code> - parse as '''e-'''
* <code>duration</code> - parse as '''dt-'''
* <code>photo</code> - parse as '''u-'''
* <code>summary</code>
* <code>author</code> - including compat root <code>vcard</code> in the absence of <code>h-card</code>
* <code>nutrition</code>
* <code>category</code>
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, rel=tag was the typical way to tag an hrecipe. Thus parsers should look for rel=tag hyperlinks inside an hrecipe, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.

== Background ==
h-recipe is based on the existing [[hRecipe]] specification.

== See Also ==

* [[h-recipe-feedback]]
* [[microformats-2]]
* [[h-card]] can be embedded in h-recipe
* [[hRecipe]] is the classic microformat replaced by h-recipe

[[Category:Draft Specifications]]

comment-brainstorming

2022-07-13T22:58:05Z

Btrem: /* Distinction between Comment and List of Comments */ Grammatical correction.

{{DISPLAYTITLE:Brainstorming for a Comment Microformat}}

{{instead|https://indieweb.org/reply and https://indieweb.org/comments}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==
Shortform: How do you publish comments on your own site, and how do you publish comments others have made on your posts?

Longform: How do you publish your own comments, others' comments on your stuff, and how do you track comments? How do you track the comments you have made on blogs, comments made on blogs you're interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Distinction between Comment and List of Comments ==
Ideally, each comment/reply should have its own permalink page, but also get copied into the markup of the post it's in reply to. Should the markup of the two cases differ? We should be able to solve both problems by extending <code>h-entry</code> a little.

* A reply on its own page is just another h-entry. The presence of u-in-reply-to implies its a reply (of a sort, could also be a special reply like an RSVP).
* If a comment does have its own permalink page and also copied to a list of comments on a post, it should likely be marked up as an [[h-cite]] in the list of comments, and link to its canonical copy on its own page.
* If a comment only exists as part of a list of comments, then using [[h-entry]] for it there seems fine, since that's likely the (only?) canonical copy of the comment. [[User:Tantek|Tantek]] 21:27, 12 July 2015 (UTC)

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== microformats2 p-comment h-entry ==

For publishing others' comments on your posts, including syndicating in others' comment posts onto your posts:

=== Proposal ===
How to:
* post h-entry with property <code>p-comment h-entry</code> (child) for a comment
* one such <code>p-comment h-entry</code> per comment
* each comment should have an ID attribute and a <code>u-url</code> permalink inside
** maybe with <code>dt-published</code> on same element or child <code><time></code> element
** if comment was syndicated in, link to original with <code>u-url</code> rather than local ID.
* <code>u-in-reply-to</code> on the child comments so they can be easily extracted out of context
** e.g. a simple <code><a href="" class="u-in-reply-to"></a></code> inside the <code>p-comment h-entry</code> would connect the context of the page URL (post permalink) as what is being replied to.
* <code>p-content</code> for the contents of plain text comments
** <code>e-content</code> if you trust the markup from others' comments (or your comment entry HTML stripping/simplifying code)
* explicit <code>p-name</code> markup either the whole p-content of the comment, or perhaps the first sentence as a simple abbreviation (perhaps useful for syndicating the comments into a feed).
* should have <code>p-author h-card</code> for the comment author

Notes:
* no need for h-feed because p-comment property value can already be an array
* any consumer of the comments can decide sort order for themselves, i.e.
** published order (order in the p-comment array)
** chronological order by dt-published of the p-comment h-entry elements
** or reverse chronological order using the same
* No real need for h-comment on the child h-entries as h-entry already covers everything a comment needs
*** and simply adding <code>u-in-reply-to</code> isn't really sufficient to justify the overhead/complexity of a new root microformat "h-comment"

<source lang=html4strict>
<div class="h-entry">
<h1 class="p-name">A Blog Post</h1>

•••

<div class="p-comment h-entry" id="comment-1"><a href="" class="u-in-reply-to"></a>
<a class="p-author h-card" href=...><img alt=author1 src=...></a>
<span class="p-name p-content">The First Comment</span>
(<a class="u-url dt-published" href="#comment-1">YYYY-DD-MM HH:MM</a>)
</div>
<div class="p-comment h-entry" id="comment-2"><a href="" class="u-in-reply-to"></a>
<a class="p-author h-card" href=...><img alt=author2 src=...></a>
<span class="p-name p-content">The Second Comment</span>
(<a class="u-url dt-published" href="#comment-2">YYYY-DD-MM HH:MM</a>)
</div>
•
•
•
</div>
</source>

=== Questions ===
==== Use case for same page u-in-reply-to ====
Q: What is the use-case for the same page u-in-reply-to?

A: The use-case for the same page u-in-reply-to is applications/sites that may subscribe to the comments as a feed, perhaps mix them in with other comments/entries. Having an explicit u-in-reply-to makes the comment portable. It's not critical, but it is also a simple/good pattern that encourages extracted data to be self-contained in general.

* Note: this use-case is currently theoretical, no one is actually doing or asking to do this yet. [[User:Tantek|Tantek]] 20:09, 12 July 2015 (UTC)

=== Notes ===
Note simplifications from [[#microformats2_h-feed_p-comments|microformats2 h-feed p-comments proposal]]:
* no <code>h-feed</code>
* one fewer div / less hierarchy than proposal above

== microformats2 h-feed p-comments ==

For publishing others' comments on your posts:

=== Proposal ===

* h-entry with child <code>h-feed p-comments</code>
** h-feed because it’s a bunch of h-entries in (reverse) chronological order
** p-comments to explicitly declare the children as comments, expose array on <code>hEntryObject.comments</code>
** No real need for h-comment on the child h-entries as h-entry already covers everything a comment needs
* Each comment should have an ID attribute and a <code>u-url</code>
* Perhaps <code>u-in-reply-to</code> on the child comments so they can be taken out of context and still used?
** Where would it go in markup?

<source lang=html4strict>
<div class="h-entry">
<h1 class="p-name">A Blog Post</h1>

•••

<div class="h-feed p-comments">
<div class="h-entry" id="comment-1">
<h2 class="p-name">The First Comment</h2>
</div>
<div class="h-entry" id="comment-2">
<h2 class="p-name">The Second Comment</h2>
</div>
•
•
•
</div>
</div>
</source>

* -1 for too much markup compared to .h-entry > .h-entry.p-comment --[[User:Barnabywalters|bw]] 09:54, 13 May 2013 (UTC)

== older pre-microformats2 proposals ==

=== Schema I ===
Proposal:
* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''bookmark''' (comment-link) 60%
** By adding "bookmark" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a link to a key entry point within an extended document.

==== Example ====

* source: [http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7]
* See also [[comment-brainstorming#Working_Examples| Working Examples]]

<pre>
<div class="comment hentry" id="comment-7">
<p><span class="entry-title">
<cite class="author vcard">
<a class="url fn" href="http://notizblog.org" rel="contact external" title="Link to Matthias Pfefferle">Matthias Pfefferle</a>
</cite> said
</span>
<span class="comment-date">about:
<abbr class="updated" title="2008-09-02T01:20:32+01:00">85 days ago</abbr>
</span></p>
<div class="entry-content">
<q cite="http://notizblog.org">Awesome! It works perfect for me.
Do you know if its possible to use the firefox microformats api with ubiquity?
And by the way... nice webslices implementation on your blog.</q>
</div>
<p><a rel="bookmark" href="http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7" title="Permalink to this comment">Permalink</a></p>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<title>Matthias Pfefferle said</title>
<id>http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7</id>
<link rel="alternate" href="http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7"
title="Permalink to this comment" type="text/html"/>
<updated>2008-09-02T01:20:32+01:00</updated>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<q cite="http://notizblog.org">
Awesome! It works perfect for me.
Do you know if its possible to use the firefox microformats api with ubiquity?
And by the way... nice webslices implementation on your blog.</q>
</div>
</content>
<author>
<name>Matthias Pfefferle</name>
<uri>http://notizblog.org</uri>
</author>
</entry>
</pre>

==== Working Examples ====

* Comments Marked up using just [[hatom]] [http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0 example]
** hAtom to Atom transformation [http://transformr.co.uk/hatom/http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0 example]
** Screen grab of atom feed viewed in Safari web browser [http://weborganics.co.uk/files/Capture.jpg example]

* Comments marked up using [[hAtom]] [http://www.csarven.ca/my-responses-are-in-white example] (note: <code>rel="in-reply-to"</code> usage in comments)
** hAtom to Atom transformation [http://transformr.co.uk/hatom/http://www.csarven.ca/my-responses-are-in-white example]

====Parser Notes====

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

====Summary====

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]]

====References====

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]

====Design Notes====
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

=== Schema II ===
Proposal:
* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

==== Details ====

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

==== Specific Example from the Wild ====

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

====Feedback====

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

=== hAtom and in-reply-to ===

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).

hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

=== Idea Consolidation ===

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

==== use hAtom Entry for a comment ====

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]
** +1 [[User:Csarven|Sarven Capadisli]]
** +1 [[User:Singpolyma|Singpolyma]]

==== mark the comment permalink with rel="reply" ====

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.
*** Agreed, this needs separate analysis with more use cases [[User:WebOrganics|Martin McEvoy]]

==== mark the comment permalink with rel="in-reply-to" ====

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

==== add an independent rel="in-reply-to" link ====

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.
** [[User:Csarven|Sarven Capadisli]] +1 for optional because it has potential to handle various types of commenting where an hentry is a ''response'' to another hentry (anywhere):
*** chronological comments
*** threaded comments
*** a blog entry as a reaction to another blog entry
*** microblogging replies

==== add class="comment" to the comment Entry ====

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 95% (note the usual DL/DT issues in some Blogger templates)
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** 0 [[User:DavidJanes|David Janes]] although it covers 100% of the examples, hAtom does have the concept of a cluster of related Entries, and thus I feel it would be better modeled that way.

==== add hAtom Entry Feed around all comments ====

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]
** -1 un-necessary just use <nowiki>class="comments"</nowiki> [[User:WebOrganics|Martin McEvoy]]
** 0 unnecessary where there is an indicator for each comment entry if they are chronologically listed as a response to the main post. Perhaps for threaded comments, however, in that case, <nowiki>class="replies"</nowiki> or <nowiki>class="comments"</nowiki> may be more suitable. [[User:Csarven|Sarven Capadisli]]

==== add class="comments" (or similar) to a element around all comments ====

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.
** +1 There is no reason why not [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:Csarven|Sarven Capadisli]]. I also prefer <code>class="replies"</code> as it is consistent with the vocabulary in Atom Threaded Extensions.
** -1 class=hfeed is more generic and conveys the meaning of "reply" when nested [[User:Singpolyma|Singpolyma]]

=== use XOXO to mark up comments ===

* notes:
* test cases covered:
* comments and votes:

=== Twitter is a comments system ===

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]
** -1 [[User:DavidJanes|David Janes]]. Twitter has nothing in common with the other comments system listed. In particular, all replies on Twitter are first class "posts" on your own twitter stream, are done in your own user context, and may not even be replies as they may be conversation initiations.
** +1 [[User:Csarven|Sarven Capadisli]]. Microblogging notices that '''only''' lead with the "@" character (see twitter.com or identi.ca: e.g., "@username Monkey see monkey do") can be considered as ''replies''. If replies are considered to be comments then the system caters user commenting. However, not all notices are comments (responses, replies) because they are standalone messages. The "@" convention is considered to be a reply since the notice also ends up in that user's replies stream. A side note here: using <code>rel="in-reply-to"</code> on the "in reply to" anchor in notices that lead with "@" creates a linkable comment.

=== A comment microformat should deal with hierarchically nested comments ===

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

=== if hAtom Entry is used, the Entry Title if not present should be ''X'' ===

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]
** [[User:DavidJanes|David Janes]] I'm happy to have whatever made up by parser implementers, which seems to be the way Atom feeds happen today. I have issues with specing English words, as it's non-I18N friendly.
** -1 because entry-title doesn't have to be an explicit title that is entered by the commenter. entry-title could be based on the information that already exists e.g., "John Smith commented on 2008-11-24". I don't think making up data (even if it is "X" or null) from thin air to satisfy the parsers is the right approach. This also wasn't the case for regular (non-comment) hAtom Entries. [[User:Csarven|Sarven Capadisli]]

=== ''suggested usage template for above'' ===

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

== See Also ==

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2022-07-13T20:37:12Z

Btrem: /* Problem */ Minor grammatical corrections.

{{DISPLAYTITLE:Brainstorming for a Comment Microformat}}

{{instead|https://indieweb.org/reply and https://indieweb.org/comments}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==
Shortform: How do you publish comments on your own site, and how do you publish comments others have made on your posts?

Longform: How do you publish your own comments, others' comments on your stuff, and how do you track comments? How do you track the comments you have made on blogs, comments made on blogs you're interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Distinction between Comment and List of Comments ==
Ideally, each comment/reply should have its own permalink page, but also get copied into the markup of the post its in reply to. Should the markup of the two cases differ? We should be able to solve both problems by extending <code>h-entry</code> a little.

* A reply on its own page is just another h-entry. The presence of u-in-reply-to implies its a reply (of a sort, could also be a special reply like an RSVP).
* If a comment does have its own permalink page and also copied to a list of comments on a post, it should likely be marked up as an [[h-cite]] in the list of comments, and link to its canonical copy on its own page.
* If a comment only exists as part of a list of comments, then using [[h-entry]] for it there seems fine, since that's likely the (only?) canonical copy of the comment. [[User:Tantek|Tantek]] 21:27, 12 July 2015 (UTC)

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== microformats2 p-comment h-entry ==

For publishing others' comments on your posts, including syndicating in others' comment posts onto your posts:

=== Proposal ===
How to:
* post h-entry with property <code>p-comment h-entry</code> (child) for a comment
* one such <code>p-comment h-entry</code> per comment
* each comment should have an ID attribute and a <code>u-url</code> permalink inside
** maybe with <code>dt-published</code> on same element or child <code><time></code> element
** if comment was syndicated in, link to original with <code>u-url</code> rather than local ID.
* <code>u-in-reply-to</code> on the child comments so they can be easily extracted out of context
** e.g. a simple <code><a href="" class="u-in-reply-to"></a></code> inside the <code>p-comment h-entry</code> would connect the context of the page URL (post permalink) as what is being replied to.
* <code>p-content</code> for the contents of plain text comments
** <code>e-content</code> if you trust the markup from others' comments (or your comment entry HTML stripping/simplifying code)
* explicit <code>p-name</code> markup either the whole p-content of the comment, or perhaps the first sentence as a simple abbreviation (perhaps useful for syndicating the comments into a feed).
* should have <code>p-author h-card</code> for the comment author

Notes:
* no need for h-feed because p-comment property value can already be an array
* any consumer of the comments can decide sort order for themselves, i.e.
** published order (order in the p-comment array)
** chronological order by dt-published of the p-comment h-entry elements
** or reverse chronological order using the same
* No real need for h-comment on the child h-entries as h-entry already covers everything a comment needs
*** and simply adding <code>u-in-reply-to</code> isn't really sufficient to justify the overhead/complexity of a new root microformat "h-comment"

<source lang=html4strict>
<div class="h-entry">
<h1 class="p-name">A Blog Post</h1>

•••

<div class="p-comment h-entry" id="comment-1"><a href="" class="u-in-reply-to"></a>
<a class="p-author h-card" href=...><img alt=author1 src=...></a>
<span class="p-name p-content">The First Comment</span>
(<a class="u-url dt-published" href="#comment-1">YYYY-DD-MM HH:MM</a>)
</div>
<div class="p-comment h-entry" id="comment-2"><a href="" class="u-in-reply-to"></a>
<a class="p-author h-card" href=...><img alt=author2 src=...></a>
<span class="p-name p-content">The Second Comment</span>
(<a class="u-url dt-published" href="#comment-2">YYYY-DD-MM HH:MM</a>)
</div>
•
•
•
</div>
</source>

=== Questions ===
==== Use case for same page u-in-reply-to ====
Q: What is the use-case for the same page u-in-reply-to?

A: The use-case for the same page u-in-reply-to is applications/sites that may subscribe to the comments as a feed, perhaps mix them in with other comments/entries. Having an explicit u-in-reply-to makes the comment portable. It's not critical, but it is also a simple/good pattern that encourages extracted data to be self-contained in general.

* Note: this use-case is currently theoretical, no one is actually doing or asking to do this yet. [[User:Tantek|Tantek]] 20:09, 12 July 2015 (UTC)

=== Notes ===
Note simplifications from [[#microformats2_h-feed_p-comments|microformats2 h-feed p-comments proposal]]:
* no <code>h-feed</code>
* one fewer div / less hierarchy than proposal above

== microformats2 h-feed p-comments ==

For publishing others' comments on your posts:

=== Proposal ===

* h-entry with child <code>h-feed p-comments</code>
** h-feed because it’s a bunch of h-entries in (reverse) chronological order
** p-comments to explicitly declare the children as comments, expose array on <code>hEntryObject.comments</code>
** No real need for h-comment on the child h-entries as h-entry already covers everything a comment needs
* Each comment should have an ID attribute and a <code>u-url</code>
* Perhaps <code>u-in-reply-to</code> on the child comments so they can be taken out of context and still used?
** Where would it go in markup?

<source lang=html4strict>
<div class="h-entry">
<h1 class="p-name">A Blog Post</h1>

•••

<div class="h-feed p-comments">
<div class="h-entry" id="comment-1">
<h2 class="p-name">The First Comment</h2>
</div>
<div class="h-entry" id="comment-2">
<h2 class="p-name">The Second Comment</h2>
</div>
•
•
•
</div>
</div>
</source>

* -1 for too much markup compared to .h-entry > .h-entry.p-comment --[[User:Barnabywalters|bw]] 09:54, 13 May 2013 (UTC)

== older pre-microformats2 proposals ==

=== Schema I ===
Proposal:
* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''bookmark''' (comment-link) 60%
** By adding "bookmark" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a link to a key entry point within an extended document.

==== Example ====

* source: [http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7]
* See also [[comment-brainstorming#Working_Examples| Working Examples]]

<pre>
<div class="comment hentry" id="comment-7">
<p><span class="entry-title">
<cite class="author vcard">
<a class="url fn" href="http://notizblog.org" rel="contact external" title="Link to Matthias Pfefferle">Matthias Pfefferle</a>
</cite> said
</span>
<span class="comment-date">about:
<abbr class="updated" title="2008-09-02T01:20:32+01:00">85 days ago</abbr>
</span></p>
<div class="entry-content">
<q cite="http://notizblog.org">Awesome! It works perfect for me.
Do you know if its possible to use the firefox microformats api with ubiquity?
And by the way... nice webslices implementation on your blog.</q>
</div>
<p><a rel="bookmark" href="http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7" title="Permalink to this comment">Permalink</a></p>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<title>Matthias Pfefferle said</title>
<id>http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7</id>
<link rel="alternate" href="http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0#comment-7"
title="Permalink to this comment" type="text/html"/>
<updated>2008-09-02T01:20:32+01:00</updated>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<q cite="http://notizblog.org">
Awesome! It works perfect for me.
Do you know if its possible to use the firefox microformats api with ubiquity?
And by the way... nice webslices implementation on your blog.</q>
</div>
</content>
<author>
<name>Matthias Pfefferle</name>
<uri>http://notizblog.org</uri>
</author>
</entry>
</pre>

==== Working Examples ====

* Comments Marked up using just [[hatom]] [http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0 example]
** hAtom to Atom transformation [http://transformr.co.uk/hatom/http://weborganics.co.uk/articles/show/ubiquity-the-best-thing-since-web2-0 example]
** Screen grab of atom feed viewed in Safari web browser [http://weborganics.co.uk/files/Capture.jpg example]

* Comments marked up using [[hAtom]] [http://www.csarven.ca/my-responses-are-in-white example] (note: <code>rel="in-reply-to"</code> usage in comments)
** hAtom to Atom transformation [http://transformr.co.uk/hatom/http://www.csarven.ca/my-responses-are-in-white example]

====Parser Notes====

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

====Summary====

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]]

====References====

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]

====Design Notes====
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

=== Schema II ===
Proposal:
* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

==== Details ====

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

==== Specific Example from the Wild ====

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

====Feedback====

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

=== hAtom and in-reply-to ===

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).

hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

=== Idea Consolidation ===

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

==== use hAtom Entry for a comment ====

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]
** +1 [[User:Csarven|Sarven Capadisli]]
** +1 [[User:Singpolyma|Singpolyma]]

==== mark the comment permalink with rel="reply" ====

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.
*** Agreed, this needs separate analysis with more use cases [[User:WebOrganics|Martin McEvoy]]

==== mark the comment permalink with rel="in-reply-to" ====

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

==== add an independent rel="in-reply-to" link ====

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.
** [[User:Csarven|Sarven Capadisli]] +1 for optional because it has potential to handle various types of commenting where an hentry is a ''response'' to another hentry (anywhere):
*** chronological comments
*** threaded comments
*** a blog entry as a reaction to another blog entry
*** microblogging replies

==== add class="comment" to the comment Entry ====

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 95% (note the usual DL/DT issues in some Blogger templates)
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** 0 [[User:DavidJanes|David Janes]] although it covers 100% of the examples, hAtom does have the concept of a cluster of related Entries, and thus I feel it would be better modeled that way.

==== add hAtom Entry Feed around all comments ====

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]
** -1 un-necessary just use <nowiki>class="comments"</nowiki> [[User:WebOrganics|Martin McEvoy]]
** 0 unnecessary where there is an indicator for each comment entry if they are chronologically listed as a response to the main post. Perhaps for threaded comments, however, in that case, <nowiki>class="replies"</nowiki> or <nowiki>class="comments"</nowiki> may be more suitable. [[User:Csarven|Sarven Capadisli]]

==== add class="comments" (or similar) to a element around all comments ====

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.
** +1 There is no reason why not [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:Csarven|Sarven Capadisli]]. I also prefer <code>class="replies"</code> as it is consistent with the vocabulary in Atom Threaded Extensions.
** -1 class=hfeed is more generic and conveys the meaning of "reply" when nested [[User:Singpolyma|Singpolyma]]

=== use XOXO to mark up comments ===

* notes:
* test cases covered:
* comments and votes:

=== Twitter is a comments system ===

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]
** -1 [[User:DavidJanes|David Janes]]. Twitter has nothing in common with the other comments system listed. In particular, all replies on Twitter are first class "posts" on your own twitter stream, are done in your own user context, and may not even be replies as they may be conversation initiations.
** +1 [[User:Csarven|Sarven Capadisli]]. Microblogging notices that '''only''' lead with the "@" character (see twitter.com or identi.ca: e.g., "@username Monkey see monkey do") can be considered as ''replies''. If replies are considered to be comments then the system caters user commenting. However, not all notices are comments (responses, replies) because they are standalone messages. The "@" convention is considered to be a reply since the notice also ends up in that user's replies stream. A side note here: using <code>rel="in-reply-to"</code> on the "in reply to" anchor in notices that lead with "@" creates a linkable comment.

=== A comment microformat should deal with hierarchically nested comments ===

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

=== if hAtom Entry is used, the Entry Title if not present should be ''X'' ===

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]
** [[User:DavidJanes|David Janes]] I'm happy to have whatever made up by parser implementers, which seems to be the way Atom feeds happen today. I have issues with specing English words, as it's non-I18N friendly.
** -1 because entry-title doesn't have to be an explicit title that is entered by the commenter. entry-title could be based on the information that already exists e.g., "John Smith commented on 2008-11-24". I don't think making up data (even if it is "X" or null) from thin air to satisfy the parsers is the right approach. This also wasn't the case for regular (non-comment) hAtom Entries. [[User:Csarven|Sarven Capadisli]]

=== ''suggested usage template for above'' ===

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

== See Also ==

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

h-review

2022-01-21T21:52:07Z

Btrem: /* Properties */ Added missing space.

{{DISPLAYTITLE:h-review}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-review</dfn> is a simple, open format for publishing reviews on the web. h-review is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-review is the [[microformats2]] update to [[hReview]].

{{cc0-owfa-license}}

== Example ==
Here is a simple review example:

<source lang=html4strict>
<div class="h-review">
<h1 class="p-name">Microformats: is structured data worth it?</h1>

<blockquote>
<a class="p-item h-item" href="http://microformats.org">Microformats</a> are the simplest way to publish structured data on the web.
</blockquote>

<p>
<data class="p-rating" value="5">★★★★★</data>
Published <time class="dt-published" datetime="2013-06-12 12:00:00">12<sup>th</sup> June 2013</time>
by <a class="p-author h-card" href="http://example.com">Joe Bloggs</a>.
</p>

<div class="e-content">
<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>
</div>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-review"
],
"properties": {
"name": [
"Microformats: is structured data worth it?"
],
"item": [
{
"value": "Microformats",
"type": [
"h-item"
],
"properties": {
"name": [
"Microformats"
],
"url": [
"http://microformats.org"
]
}
}
],
"rating": [
"5"
],
"published": [
"2013-06-12 12:00:00"
],
"author": [
{
"value": "Joe Bloggs",
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
],
"content": [
{
"value": "Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).",
"html": "<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-review</code>''' is a ''root class name'' that indicates the presence of an h-review.

'''p-name''', '''p-item''', '''p-rating''', '''dt-published''', '''p-author''', '''e-content''' and the other property class names listed below defined elements as ''properties'' of the h-review.

The class '''<code>h-item</code>''' is a ''root class name'' that indicates an embedded '''[[h-item]]''' for the p-item property.

The class '''<code>h-card</code>''' is a ''root class name'' that indicates an embedded '''[[h-card]]''' for the p-author property.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-review properties, inside an element with class '''h-review''':

* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing being reviewed, including embedded microformat for e.g. business or person ([[h-card]]), event ([[h-event]]), place ([[h-adr]] or [[h-geo]]), product ([[h-product]]), recipe ([[h-recipe]]), website, url, or other item ([[h-item]]).
* '''<code>p-author</code>''' - person who authored the review, optionally with an embedded [[h-card]]
* '''<code>dt-published</code>''' - date time of when the review was written and published
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-content</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - review permalink URL

All properties are optional.

Experimental properties currently in use in the wild but not (yet) part of the official h-review spec. Several of these seem to be because of h-review convergence towards [[h-entry]], as h-review gets used alongside h-entry within [[h-feed]]:

* '''<code>p-location</code>''' - location the review was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>p-summary</code>''' - short review summary
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this review. The property equivalent of [[rel-syndication]] ([https://aaronparecki.com/2018/01/29/10/ example] with [https://www.amazon.com/review/R1P2C3ATN75836/ref=pe_1098610_137716200_cm_rv_eml_rv0_rv syndication to Amazon])

== Status ==
'''h-review''' is a microformats.org draft specification. Public discussion on h-review takes place on [[h-review-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-review is ready to use.

== Property Details ==
(stub, add any property explanations here)

== Examples in the Wild ==
* … add any h-review examples you find in the wild
* https://cleverdevil.io/2015/blood-rites-book-six-of-the-dresden-files
* https://aaronparecki.com/2018/01/29/10/ (more on Aaron’s [https://aaronparecki.com/reviews review feed])

== Implementations ==
* [https://github.com/cleverdevil/Known-Reviews Reviews plugin for Known CMS] by [https://cleverdevil.io Jonathan LaCour].
** [https://github.com/cleverdevil/Known-Reviews/pull/4 pending pull request to sync with spec update 2016-05-29] -t

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hReview]] classnames on an h-review permalink page in addition to the more future-proof h-review properties, for example:

<source lang=html4strict>
<div class="h-review hreview">
<h1 class="p-name fn">My great review</h1>
</div>
</source>

See [https://aaronparecki.com/ Aaron Parecki]’s [https://aaronparecki.com/2016/12/17/8/owning-my-reviews Why Microformats? Owning My Reviews] for a reason to be backwards compatible.

=== Parser Compatibility ===
Microformats parsers should detect classic properties and parse them as microformats 2 properties. If an "h-review" is found, don't look for an "hReview" on the same element.

Compatibility root class name: hreview

Properties: (parsed as p- plain text unless otherwise specified)

* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item</code> (without vcard, vevent, hproduct) - parse as '''p-item h-item''' including backcompat nested properties:
** <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
** <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
** <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item vcard</code> - parse as '''p-item h-card''' including backcompat [[hCard]] parsing
* <code>item vevent</code> - parse as '''p-item h-event''' including backcompat [[hCalendar]] vevent property parsing
* <code>item hproduct</code> - parse as '''p-item h-product''' including backcompat [[hProduct]] parsing
* <code>reviewer</code> - parse as '''p-author''', including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-published'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-content'''
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, [[rel-tag|rel=tag]] was the typical way to tag an hreview. Thus parsers should look for rel=tag hyperlinks inside an hreview, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== prior property names ===
There may be a handful of h-reviews out there (only one known so far) that use prior h-review property names. Parsers encountering these *may* interpret them as follows:

* <code>dt-reviewed</code> treat as a fallback for '''<code>dt-published</code>'''
* <code>e-description</code> treat as a fallback for '''<code>e-content</code>'''
* <code>p-reviewer</code> treat as a fallback for '''<code>p-author</code>'''

== Background ==
h-review is based on the existing [[hReview]] specification.

== See Also ==
* [[microformats2]]
* [[h-card]]
* [[h-event]]
* [[h-adr]]
* [[h-geo]]
* [[h-product]] can all be embedded in h-review as the p-item
* [[h-item]] is a minimal microformat in case none of the others suitably represent the item being reviewed

[[Category:Draft Specifications]]

h-review

2021-12-05T22:04:47Z

Btrem: /* Properties */ Adds recipe (h-recipe) to list of things that might be reviewed in an instance of h-review.

{{DISPLAYTITLE:h-review}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-review</dfn> is a simple, open format for publishing reviews on the web. h-review is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-review is the [[microformats2]] update to [[hReview]].

{{cc0-owfa-license}}

== Example ==
Here is a simple review example:

<source lang=html4strict>
<div class="h-review">
<h1 class="p-name">Microformats: is structured data worth it?</h1>

<blockquote>
<a class="p-item h-item" href="http://microformats.org">Microformats</a> are the simplest way to publish structured data on the web.
</blockquote>

<p>
<data class="p-rating" value="5">★★★★★</data>
Published <time class="dt-published" datetime="2013-06-12 12:00:00">12<sup>th</sup> June 2013</time>
by <a class="p-author h-card" href="http://example.com">Joe Bloggs</a>.
</p>

<div class="e-content">
<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>
</div>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-review"
],
"properties": {
"name": [
"Microformats: is structured data worth it?"
],
"item": [
{
"value": "Microformats",
"type": [
"h-item"
],
"properties": {
"name": [
"Microformats"
],
"url": [
"http://microformats.org"
]
}
}
],
"rating": [
"5"
],
"published": [
"2013-06-12 12:00:00"
],
"author": [
{
"value": "Joe Bloggs",
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
],
"content": [
{
"value": "Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).",
"html": "<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-review</code>''' is a ''root class name'' that indicates the presence of an h-review.

'''p-name''', '''p-item''', '''p-rating''', '''dt-published''', '''p-author''', '''e-content''' and the other property class names listed below defined elements as ''properties'' of the h-review.

The class '''<code>h-item</code>''' is a ''root class name'' that indicates an embedded '''[[h-item]]''' for the p-item property.

The class '''<code>h-card</code>''' is a ''root class name'' that indicates an embedded '''[[h-card]]''' for the p-author property.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-review properties, inside an element with class '''h-review''':

* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing being reviewed, including embedded microformat for e.g. business or person ([[h-card]]), event ([[h-event]]), place ([[h-adr]] or [[h-geo]]), product ([[h-product]]), recipe([[h-recipe]]), website, url, or other item ([[h-item]]).
* '''<code>p-author</code>''' - person who authored the review, optionally with an embedded [[h-card]]
* '''<code>dt-published</code>''' - date time of when the review was written and published
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-content</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - review permalink URL

All properties are optional.

Experimental properties currently in use in the wild but not (yet) part of the official h-review spec. Several of these seem to be because of h-review convergence towards [[h-entry]], as h-review gets used alongside h-entry within [[h-feed]]:

* '''<code>p-location</code>''' - location the review was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>p-summary</code>''' - short review summary
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this review. The property equivalent of [[rel-syndication]] ([https://aaronparecki.com/2018/01/29/10/ example] with [https://www.amazon.com/review/R1P2C3ATN75836/ref=pe_1098610_137716200_cm_rv_eml_rv0_rv syndication to Amazon])

== Status ==
'''h-review''' is a microformats.org draft specification. Public discussion on h-review takes place on [[h-review-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-review is ready to use.

== Property Details ==
(stub, add any property explanations here)

== Examples in the Wild ==
* … add any h-review examples you find in the wild
* https://cleverdevil.io/2015/blood-rites-book-six-of-the-dresden-files
* https://aaronparecki.com/2018/01/29/10/ (more on Aaron’s [https://aaronparecki.com/reviews review feed])

== Implementations ==
* [https://github.com/cleverdevil/Known-Reviews Reviews plugin for Known CMS] by [https://cleverdevil.io Jonathan LaCour].
** [https://github.com/cleverdevil/Known-Reviews/pull/4 pending pull request to sync with spec update 2016-05-29] -t

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hReview]] classnames on an h-review permalink page in addition to the more future-proof h-review properties, for example:

<source lang=html4strict>
<div class="h-review hreview">
<h1 class="p-name fn">My great review</h1>
</div>
</source>

See [https://aaronparecki.com/ Aaron Parecki]’s [https://aaronparecki.com/2016/12/17/8/owning-my-reviews Why Microformats? Owning My Reviews] for a reason to be backwards compatible.

=== Parser Compatibility ===
Microformats parsers should detect classic properties and parse them as microformats 2 properties. If an "h-review" is found, don't look for an "hReview" on the same element.

Compatibility root class name: hreview

Properties: (parsed as p- plain text unless otherwise specified)

* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item</code> (without vcard, vevent, hproduct) - parse as '''p-item h-item''' including backcompat nested properties:
** <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
** <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
** <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item vcard</code> - parse as '''p-item h-card''' including backcompat [[hCard]] parsing
* <code>item vevent</code> - parse as '''p-item h-event''' including backcompat [[hCalendar]] vevent property parsing
* <code>item hproduct</code> - parse as '''p-item h-product''' including backcompat [[hProduct]] parsing
* <code>reviewer</code> - parse as '''p-author''', including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-published'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-content'''
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, [[rel-tag|rel=tag]] was the typical way to tag an hreview. Thus parsers should look for rel=tag hyperlinks inside an hreview, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== prior property names ===
There may be a handful of h-reviews out there (only one known so far) that use prior h-review property names. Parsers encountering these *may* interpret them as follows:

* <code>dt-reviewed</code> treat as a fallback for '''<code>dt-published</code>'''
* <code>e-description</code> treat as a fallback for '''<code>e-content</code>'''
* <code>p-reviewer</code> treat as a fallback for '''<code>p-author</code>'''

== Background ==
h-review is based on the existing [[hReview]] specification.

== See Also ==
* [[microformats2]]
* [[h-card]]
* [[h-event]]
* [[h-adr]]
* [[h-geo]]
* [[h-product]] can all be embedded in h-review as the p-item
* [[h-item]] is a minimal microformat in case none of the others suitably represent the item being reviewed

[[Category:Draft Specifications]]

h-review

2021-12-05T22:02:03Z

Btrem: /* Properties */ spelling correction

{{DISPLAYTITLE:h-review}}
<span class="h-card vcard"><span class="p-name fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role role">Editor</span>)</span>
----
<dfn style="font-style:normal;font-weight:bold">h-review</dfn> is a simple, open format for publishing reviews on the web. h-review is one of several open [[microformats|microformat]] draft standards suitable for embedding data in HTML.

h-review is the [[microformats2]] update to [[hReview]].

{{cc0-owfa-license}}

== Example ==
Here is a simple review example:

<source lang=html4strict>
<div class="h-review">
<h1 class="p-name">Microformats: is structured data worth it?</h1>

<blockquote>
<a class="p-item h-item" href="http://microformats.org">Microformats</a> are the simplest way to publish structured data on the web.
</blockquote>

<p>
<data class="p-rating" value="5">★★★★★</data>
Published <time class="dt-published" datetime="2013-06-12 12:00:00">12<sup>th</sup> June 2013</time>
by <a class="p-author h-card" href="http://example.com">Joe Bloggs</a>.
</p>

<div class="e-content">
<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>
</div>
</div>
</source>

Parsed JSON:
<source lang=javascript>
{
"items": [
{
"type": [
"h-review"
],
"properties": {
"name": [
"Microformats: is structured data worth it?"
],
"item": [
{
"value": "Microformats",
"type": [
"h-item"
],
"properties": {
"name": [
"Microformats"
],
"url": [
"http://microformats.org"
]
}
}
],
"rating": [
"5"
],
"published": [
"2013-06-12 12:00:00"
],
"author": [
{
"value": "Joe Bloggs",
"type": [
"h-card"
],
"properties": {
"name": [
"Joe Bloggs"
],
"url": [
"http://example.com"
]
}
}
],
"content": [
{
"value": "Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).",
"html": "<p>Yes, microformats are undoubtedly great. They are the simplest way to markup structured data in HTML and reap the benefits thereof, including using your web page as your API by automatic conversion to JSON. The alternatives of microdata/schema and RDFa are much more work, require more markup, and are more complicated (harder to get right, more likely to break).</p>"
}
]
}
}
]
}
</source>

=== Get started ===
The class '''<code>h-review</code>''' is a ''root class name'' that indicates the presence of an h-review.

'''p-name''', '''p-item''', '''p-rating''', '''dt-published''', '''p-author''', '''e-content''' and the other property class names listed below defined elements as ''properties'' of the h-review.

The class '''<code>h-item</code>''' is a ''root class name'' that indicates an embedded '''[[h-item]]''' for the p-item property.

The class '''<code>h-card</code>''' is a ''root class name'' that indicates an embedded '''[[h-card]]''' for the p-author property.

See [[microformats2-parsing]] to learn more about property class names.

== Properties ==
h-review properties, inside an element with class '''h-review''':

* '''<code>p-name</code>''' - name of the review
* '''<code>p-item</code>''' - thing being reviewed, including embedded microformat for e.g. business or person ([[h-card]]), event ([[h-event]]), place ([[h-adr]] or [[h-geo]]), product ([[h-product]]), website, url, or other item ([[h-item]]).
* '''<code>p-author</code>''' - person who authored the review, optionally with an embedded [[h-card]]
* '''<code>dt-published</code>''' - date time of when the review was written and published
* '''<code>p-rating</code>''' - value from 1-5 indicating a rating for the item (5 best).
* '''<code>p-best</code>''' - define best rating value. can be numerically lower than worst.
* '''<code>p-worst</code>''' - define worst rating value. can be numerically higher than best.
* '''<code>e-content</code>''' - the full text written evaluation and opinion of the reviewer
* '''<code>p-category</code>''' - freeform categories or tags applied to the item by the reviewer
* '''<code>u-url</code>''' - review permalink URL

All properties are optional.

Experimental properties currently in use in the wild but not (yet) part of the official h-review spec. Several of these seem to be because of h-review convergence towards [[h-entry]], as h-review gets used alongside h-entry within [[h-feed]]:

* '''<code>p-location</code>''' - location the review was posted from, optionally embed [[h-card]], [[h-adr]], or [[h-geo]]
* '''<code>p-summary</code>''' - short review summary
* '''<code>u-syndication</code>''' - URL(s) of syndicated copies of this review. The property equivalent of [[rel-syndication]] ([https://aaronparecki.com/2018/01/29/10/ example] with [https://www.amazon.com/review/R1P2C3ATN75836/ref=pe_1098610_137716200_cm_rv_eml_rv0_rv syndication to Amazon])

== Status ==
'''h-review''' is a microformats.org draft specification. Public discussion on h-review takes place on [[h-review-feedback]] and the #microformats [[irc]] channel on irc.freenode.net.

h-review is ready to use.

== Property Details ==
(stub, add any property explanations here)

== Examples in the Wild ==
* … add any h-review examples you find in the wild
* https://cleverdevil.io/2015/blood-rites-book-six-of-the-dresden-files
* https://aaronparecki.com/2018/01/29/10/ (more on Aaron’s [https://aaronparecki.com/reviews review feed])

== Implementations ==
* [https://github.com/cleverdevil/Known-Reviews Reviews plugin for Known CMS] by [https://cleverdevil.io Jonathan LaCour].
** [https://github.com/cleverdevil/Known-Reviews/pull/4 pending pull request to sync with spec update 2016-05-29] -t

== Validating ==
{{h-spec-section-validating}}

== Backward Compatibility ==
=== Publisher Compatibility ===
For backward compatibility, you may wish to use classic [[hReview]] classnames on an h-review permalink page in addition to the more future-proof h-review properties, for example:

<source lang=html4strict>
<div class="h-review hreview">
<h1 class="p-name fn">My great review</h1>
</div>
</source>

See [https://aaronparecki.com/ Aaron Parecki]’s [https://aaronparecki.com/2016/12/17/8/owning-my-reviews Why Microformats? Owning My Reviews] for a reason to be backwards compatible.

=== Parser Compatibility ===
Microformats parsers should detect classic properties and parse them as microformats 2 properties. If an "h-review" is found, don't look for an "hReview" on the same element.

Compatibility root class name: hreview

Properties: (parsed as p- plain text unless otherwise specified)

* <code>summary</code> parse as '''<code>p-name</code>'''
* <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
* <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
* <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item</code> (without vcard, vevent, hproduct) - parse as '''p-item h-item''' including backcompat nested properties:
** <code>fn</code> - parse as '''p-name''' of the item being reviewed (p-item h-item p-name)
** <code>photo</code> - parse as '''u-photo''' of the item being reviewed (p-item h-item u-photo)
** <code>url</code> - parse as '''u-url''' of the item being reviewed (p-item h-item u-url)
* <code>item vcard</code> - parse as '''p-item h-card''' including backcompat [[hCard]] parsing
* <code>item vevent</code> - parse as '''p-item h-event''' including backcompat [[hCalendar]] vevent property parsing
* <code>item hproduct</code> - parse as '''p-item h-product''' including backcompat [[hProduct]] parsing
* <code>reviewer</code> - parse as '''p-author''', including compat root vcard in the absence of h-card
* <code>dtreviewed</code> - parse as '''dt-published'''
* <code>rating</code>
* <code>best</code>
* <code>worst</code>
* <code>description</code> - parse as '''e-content'''
* <code>rel=tag</code> - parse as '''<code>p-category</code>'''. While not a class name nor typical microformats property, [[rel-tag|rel=tag]] was the typical way to tag an hreview. Thus parsers should look for rel=tag hyperlinks inside an hreview, and take the last path segment of their "href" value as a value for a '''<code>p-category</code>''' property.
* <code>rel="self bookmark"</code> - parse as '''u-url'''. note that <code>rel</code> attribute value is treated as a space separated set, thus any presence of "self" and "bookmark" within such a set in a rel value is accepted.

Note: The [[hReview]] format has three properties which make use of <code>rel</code> attribute, these are <code>tag</code>, permalink (via the <code>self</code> and <code>bookmark</code> values) and <code>license</code>. Microformats 2 parsers {{should}} map these URLs into the page scoped rel collection.

=== prior property names ===
There may be a handful of h-reviews out there (only one known so far) that use prior h-review property names. Parsers encountering these *may* interpret them as follows:

* <code>dt-reviewed</code> treat as a fallback for '''<code>dt-published</code>'''
* <code>e-description</code> treat as a fallback for '''<code>e-content</code>'''
* <code>p-reviewer</code> treat as a fallback for '''<code>p-author</code>'''

== Background ==
h-review is based on the existing [[hReview]] specification.

== See Also ==
* [[microformats2]]
* [[h-card]]
* [[h-event]]
* [[h-adr]]
* [[h-geo]]
* [[h-product]] can all be embedded in h-review as the p-item
* [[h-item]] is a minimal microformat in case none of the others suitably represent the item being reviewed

[[Category:Draft Specifications]]

opening-hours-formats

2021-02-27T21:28:06Z

Btrem: /* opening hours property */ Fixes sentence.

{{DISPLAYTITLE:opening hours formats}}

This is part of an effort per the microformats [[process]] to research, gather examples, and brainstorm for a microformat for marking up the [[opening-hours]] for a business or organization.
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== OpenStreetMap ==
OpenStreetMap allows venues to be tagged with the [https://wiki.openstreetmap.org/wiki/Opening_hours <var>opening_hours</var>] tag. The value of this tag has been formalized and is defined in the [http://www.netzwolf.info/en/cartography/osm/time_domain/ TimeDomain specification], where there is also a JavaScript implementation.

[http://wiki.openstreetmap.org/wiki/Key:opening_hours Key:opening_hours] is also defined on the OSM Wiki.

The same string-based format is used to mark the times of religious services in places of worship using the [https://wiki.openstreetmap.org/wiki/Key:service_times <var>service_times</var>] tag, the times of collections from post boxes with the [https://wiki.openstreetmap.org/wiki/Key:collection_times <var>collection-times</var>] tag, and there is a proposal to mark venues which allow smoking (possibly in a separate area) with the [https://wiki.openstreetmap.org/wiki/Key:smoking_hours <var>smoking_hours</var>] tag, and also with the 'lit' tag to specify when a feature (e.g. building) is lit up.

A broader proposal also exists for using the <var>opening_hours</var> format for describing [https://wiki.openstreetmap.org/wiki/Conditional_restrictions conditional restrictions], for instance roads that have speed limits that vary depending on time of day, and roads that allow only specific types of traffic (buses and bicycles, for instance) during periods of the day.

Comments can also be added in quotations.

Examples:

* Tu-Su 08:00-15:00;Sa 08:00-12:00 – see [http://www.openstreetmap.org/browse/node/624582426 node:624582426], a cafe in Terlizzi, Italy.

== Google maps display ==
Google places uses this format to *display* the opening hours, and then applies some javascript to hide the lines which are not immediately useful:
The translate the day names and the time formats into the users locale.

This is clearly rendered data for end user consumption and not a format one can use to establish a standard.

See an example here with opening hours: http://maps.google.com/maps/place?cid=17374953169507020841

<source lang=html4strict>
<table style="" id="oh-ov-table" class="oh-table">
<tbody>
<tr class="oh-highlight-day">
<td class="oh-day">
Montag
</td>
<td dir="ltr">
11:00-16:00
</td>
</tr>
<tr>
<td class="oh-day">
Dienstag
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Mittwoch
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Donnerstag
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Freitag
</td>
<td dir="ltr">
11:00-16:00
</td>
</tr>
<tr>
<td class="oh-day">
Samstag
</td>
<td dir="ltr">
Geschlossen
</td>
</tr>
<tr>
<td class="oh-day">
Sonntag
</td>
<td dir="ltr">
Geschlossen
</td>
</tr>
</tbody>
</table>
</source>

== schema.org ==
=== opening hours property===
schema.org has an [https://schema.org/openingHours opening hours] <dfn>property</dfn>. Days are specified with two letter abbreviations, e.g. <abbr title="Monday">Mo</abbr>, <abbr title="Tuesday">Tu</abbr>, etc.; days can be comma separated for separate days or a range can be specified with a hyphen. Times are specified in 24 hour format. Examples:
<pre>
<data lang="en" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Open Monday, Wednesday, Friday 9am-1pm</data>
</pre>
<pre>
<data lang="en" itemprop="openingHours" value="Mo-Fr 09:00-13:00">Open Monday-Friday 9am-1pm</data>
</pre>
<pre>
<data lang="fr" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Disponible lundi, mercredi, vendredi 9:00-13:00</data>
</pre>
<pre>
<data lang="de" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Montag, Mittwoch, Freitag 9:00-13:00</data>
</pre>

Note: the examples from the [https://schema.org/openingHours schema website] use the <code>content</code> attribute on the <code>p</code> element. This does not appear to be allowed in [https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes html]. These examples were changed to use the <code>data</code> element with the <code>value</code> attribute.

=== opening hours type ===
There is also a [https://schema.org/OpeningHoursSpecification Opening Hours Specification] <dfn>type</dfn>, which can use the opening hours property along with more granular properties to specify exceptions, e.g., "open 9-6 except on New Year's Day." This type has a more complex syntax. There is a dayOfWeek property that uses a url to specify the day, e.g. https://schema.org/Tuesday. There are separate properties for opens and closes. Example:

<pre>
<p>Opening hours</p>
<p itemprop="openingHoursSpecification" itemscope itemtype="https://schema.org/OpeningHoursSpecification">
<span itemprop="dayOfWeek" href="https://schema.org/Monday">Monday</span>
<time itemprop="opens" content="09:00">9:00 AM</time> - <time itemprop="closes" content="17:00">5:00 PM</time>
</p>
<p itemprop="openingHoursSpecification" itemscope itemtype="https://schema.org/OpeningHoursSpecification">
<span itemprop="dayOfWeek" href="https://schema.org/Tuesday">Tuesday</span>
<time itemprop="opens" content="09:00:00">9:00 AM</time> - <time itemprop="closes" content="17:00:00">5:00 PM</time>
</p>
</pre>

== hCard extension workhours ==
Yandex implements a property "workhours" as an extension to [[hCard]], per http://www.step-up-web.ru/hcard/ (from [[articles-ru]])

<blockquote>
workhours — Время работы организации. Свойство не предусмотрено стандартом hCard, оно добавлено Яндексом в качестве расширения. Для указания времени работы мы рекомендуем формат, используемый в Справочнике организаций, например:

* пн-пт 9:00-18:00
* пн-пт 9:00-18:00, обед 13:00-14:00, сб-вс 10:00-17:00, обед 13:30-14:00
* пн-сб 11:00-20:00, вс 12:00-24:00
* ежедн. 10:00-24:00
* круглосуточно
</blockquote>

Translation via Google translate:

<blockquote>
workhours - Time of the organization. The property is not provided by standard hCard, it is added as an extension by Yandex. To specify the working hours, we recommend that the format used in the directory of organizations, such as:

* Mon-Fri 9:00-18:00
* Mon-Fri 9:00-18:00, lunch 13:00-14:00, Sat-Sun 10:00-17:00, lunch 13:30-14:00
* Mon-Sat 11:00-20:00, Sun 12:00-24:00
* Daily. 10:00-24:00
* around the clock
</blockquote>

Since this is a translation, it is not clear if Yandex would support parsing the translated values (they may or may not). However, the translation is still useful for consideration from a design perspective towards a microformats solution.

== see also ==
* [[opening-hours]]
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

opening-hours-brainstorming

2021-02-27T21:14:12Z

Btrem: /* Jacky's Idea for Rendering a Week of Hours */ Adds indentation to make thread easier to follow.

{{DISPLAYTITLE:opening hours brainstorming}}
This is part of an effort per the microformats [[process]] to research, gather examples, and brainstorm for a microformat for marking up the '''opening hours''' for a business or organization.
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== brainstorming ==
Brainstorming proposals should only be written up after examples and formats research has been completed per the [[process]].

=== calendar of unnamed events ===
As suggested by jacky in [[irc]], a calendar of unnamed events (using [[h-event]]), perhaps nested in the venue's [[h-card]], maybe sufficient to imply/convey opening hours for those days.

* I think opening hours is worth its own type. `h-x-opening-hours` or some such thing. With a single property that is a nested h-event. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:38, 20 February 2021 (UTC)
** My only hesistation against making a new type is that the 'specifics' are things that can be defined by a machine (when to start, when to end) and everything else is human-specific (and thus a rendering layer). [[User:Jacky|Jacky]] 18:41, 20 Feb 2021 PST
** A new microformat (h-*) feels like it's taking on too big of a problem when we can probably find smaller problems to solve first (per [[process|The microformats process]]). A problem I think I saw come up in chat is how to represent the time for a day of the week. Maybe we could work on how to represent a "day-of-week relative" time with existing properties in an h-event. [[User:GRegorLove|gRegor]] ([[User talk:GRegorLove|talk]]) 20:58, 23 February 2021 (UTC)
*** What is the use case for "'day-of-week relative' time"? I assume this is something different to a specific date, so not Saturday 2021-02-27T13:00. The problem is html5's datetime attribute doesn't have a way to specify day of week. Such things are in various iso specs, but those conventions would have to be ported to html5. That's obviously outside the scope of microformats. If you have details about what came up in chat, I'd be curious to see the problem. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 21:03, 27 February 2021 (UTC)

==== [[User:Jacky|Jacky]]'s Idea for Rendering a Week of Hours ====

Main Page:
<pre>
<aside class="h-card">
We're open <a class="h-event u-url" href="/open-days" rel="calendar" title="Open Hours">Tuesdays to Fridays from 10 AM to 9 PM</a>, closed Sundays, Saturdays and Mondays.
</aside>
</pre>

Event Page:
<pre>
<aside class="h-feed">
<h2 class="p-name">Hours</h2>
<p class="h-event" id="Monday">Closed on <a href="#Monday" class="u-url p-name">Mondays</a>.</p>
<p class="h-event" id="Tuesday">Open on <a href="#Tuesday" class="u-url p-name">Tuesdays</a> from <time class="dt-start" datetime="09:00:00">9 AM</time> to <time class="dt-end" datetime="18:00:00">6 PM</time>.</p>
</aside>
</pre>

Some thoughts:

* Using `h-feed` for a feed of events raises some issues: [[h-feed]] is explicitly described as "a stream or feed of h-entry posts". I suppose that could be changed, but it requires changing a fairly stable spec. And it means that authors who are new to microformats will have to learn how to distinguish them. I think a new type should be used to avoid confusion. Note that [[hCalendar]] was created as a 1:1 html version of iCalendar, a ''collection'' of events; microformats2's [[h-event]] is for a ''single'' event. If we go with a feed of events, we should revive the iCalendar idea. We need to give it a name that makes it clear it's a feed of events. Perhaps '''h-feed-events'''? [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:15, 21 February 2021 (UTC)
** There are two GitHub issues (https://github.com/microformats/h-feed/issues/3 and https://github.com/microformats/h-entry/issues/16) arguing against me and for broadening [[h-feed]]'s use. So that might be the way to go. I still think we need a way to determine that the feed specifies opening hours, perhaps with a p-children-type for h-feed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 20:11, 21 February 2021 (UTC)

* I don't understand how the <code>id</code> attributes and url fragment urls are supposed to work. The fragment urls link to their own p containers. Is that supposed to convey that this is a repeating event? [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:27, 21 February 2021 (UTC)

=== simple class proposal ===
proposed format:

<nowiki><span class="operating-hours">
Tu-Sa 08:00-15:00; Sa 08:00-12:00
</span></nowiki>

see it here: http://www.geodatacheck.com/p/2

Use a semicolon to separate the different days or or time ranges.
Use two letter english day names. Times are local times with leading zero

This is the format as used in openstreetmap.org for a node description with opening hours. Openstreetmap has very rigid semantics, so it makes sense to follow their format.
There are several issues with proposal:
<div class="issues discussion">
* '''citation needed''' - please provide a link to where Openstreetmap defines this format on the [[opening-hours-formats]] page. - [[User:Tantek|Tantek]] 18:08, 21 December 2012 (UTC)
* no real world use case. how would such a microformat help users? this should be documented in the introduction to an [[opening-hours]] effort. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* proposal is 'a priori' - that is proposal has been made without documentation of real world examples per the [[process]]. please document real world [[examples]] of pages that would benefit from this markup so we can design the format only for their needs and no more. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* did not research previous formats. we have no idea if this effort is reinventing various wheels or not. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* uses new datetime formats, e.g. "Tu-Sa". Is there some way to re-use ISO8601 instead? - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* not international, e.g. "Tu-Sa". this could be addressed with ISO8601 usage instead. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)

I don't see anything in [https://www.iso.org/iso-8601-date-and-time-format.html ISO 8601] to specify days of the week. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 17:02, 16 December 2020 (UTC)
</div>

=== Operating Hours Brainstorming ===
:This section was merged from [[operating-hours]]

This section documents a method that can be used to mark up the operating hours of stores, restaurants, museums, offices, and other establishments that have set hours and are open on a regular basis. This is based on the [[hCalendar]] microformat.

==== Discussion Participants ====
===== Authors =====
* [http://dragotown.com Nick Drago]
* [http://suda.co.uk/ Brian Suda]

===== Contributors =====

==== Introduction ====
This effort came about as a result of the need for a human and machine readable markup format that can be used to define the operating hours of establishments.

Stores, businesses, etc. often provide their operating hours on their websites. With the addition of a small bit of markup, they are able to define their operating hours on their websites in such a way that spiders and other aggregators can retrieve such hours, automatically convert them to the iCalendar format, and use this data in any iCalendar application or service.

==== Using RRULE in hCalendar ====
This was suggested [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008562.html] by Brian. Is this the most appropriate method? --Nick

<pre>
// example definition of operating hours using RRULE in hCalendar

<h1>Pardon the Interruption</h1>
<p class="vevent">
<a class="url uid summary"
href="http://sports.espn.go.com/...">Pardon the Interruption</a>
is a <span class="category">TV</span> <span
class="category">sports</span> show.
<abbr class="dtstart" title="2001-10-22">It airs</abbr>
<span class="rrule">
<span class="freq">weekly</span>
<abbr class="byday" title="mo,tu,we,th,fr">Monday to
Friday</abbr> at <abbr class="byhour" title="5">5:30pm</abbr>
</span>


<abbr class="tzid" title="US-Eastern">ET</abbr> on ESPN.

The hosts of the show are longtime friends
<span class="hcard">
<span class="fn n">
<span class="given-name">Tony</span>
<span class="family-name">Kornheiser</span>
</span>
</span>
and ... (hCard for Michael Wilbon not shown)
<span class="description">They discuss - and frequently argue over
- the top stories of the
day in "sports... and other stuff".</span>
</p>
</pre>

==== References ====
===== Normative References =====
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[hcard]]
* [[hCalendar]]
* [http://www.ietf.org/rfc/rfc2445.txt iCalendar RFC2445]
* [http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html ISO 8601]

===== Informative References =====
* [http://en.wikipedia.org/wiki/ISO_8601 Wikipedia article on ISO 8601]
* [http://www.xfront.com/microformats/hCalendar_part2.html Tutorial on recurring events in hCalendar]

===== Related =====
* [[operating-hours-examples]]
* [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008562.html Corresponding thread from uf-discuss]

== related ==
* [[opening-hours]]
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== see also ==
* [[hCard]]
* [[hCalendar]]

opening-hours-brainstorming

2021-02-27T21:03:39Z

Btrem: /* calendar of unnamed events */ Asking for use case for day of week with time.

{{DISPLAYTITLE:opening hours brainstorming}}
This is part of an effort per the microformats [[process]] to research, gather examples, and brainstorm for a microformat for marking up the '''opening hours''' for a business or organization.
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== brainstorming ==
Brainstorming proposals should only be written up after examples and formats research has been completed per the [[process]].

=== calendar of unnamed events ===
As suggested by jacky in [[irc]], a calendar of unnamed events (using [[h-event]]), perhaps nested in the venue's [[h-card]], maybe sufficient to imply/convey opening hours for those days.

* I think opening hours is worth its own type. `h-x-opening-hours` or some such thing. With a single property that is a nested h-event. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:38, 20 February 2021 (UTC)
** My only hesistation against making a new type is that the 'specifics' are things that can be defined by a machine (when to start, when to end) and everything else is human-specific (and thus a rendering layer). [[User:Jacky|Jacky]] 18:41, 20 Feb 2021 PST
** A new microformat (h-*) feels like it's taking on too big of a problem when we can probably find smaller problems to solve first (per [[process|The microformats process]]). A problem I think I saw come up in chat is how to represent the time for a day of the week. Maybe we could work on how to represent a "day-of-week relative" time with existing properties in an h-event. [[User:GRegorLove|gRegor]] ([[User talk:GRegorLove|talk]]) 20:58, 23 February 2021 (UTC)
*** What is the use case for "'day-of-week relative' time"? I assume this is something different to a specific date, so not Saturday 2021-02-27T13:00. The problem is html5's datetime attribute doesn't have a way to specify day of week. Such things are in various iso specs, but those conventions would have to be ported to html5. That's obviously outside the scope of microformats. If you have details about what came up in chat, I'd be curious to see the problem. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 21:03, 27 February 2021 (UTC)

==== [[User:Jacky|Jacky]]'s Idea for Rendering a Week of Hours ====

Main Page:
<pre>
<aside class="h-card">
We're open <a class="h-event u-url" href="/open-days" rel="calendar" title="Open Hours">Tuesdays to Fridays from 10 AM to 9 PM</a>, closed Sundays, Saturdays and Mondays.
</aside>
</pre>

Event Page:
<pre>
<aside class="h-feed">
<h2 class="p-name">Hours</h2>
<p class="h-event" id="Monday">Closed on <a href="#Monday" class="u-url p-name">Mondays</a>.</p>
<p class="h-event" id="Tuesday">Open on <a href="#Tuesday" class="u-url p-name">Tuesdays</a> from <time class="dt-start" datetime="09:00:00">9 AM</time> to <time class="dt-end" datetime="18:00:00">6 PM</time>.</p>
</aside>
</pre>

Some thoughts:

Using `h-feed` for a feed of events raises some issues: [[h-feed]] is explicitly described as "a stream or feed of h-entry posts". I suppose that could be changed, but it requires changing a fairly stable spec. And it means that authors who are new to microformats will have to learn how to distinguish them. I think a new type should be used to avoid confusion. Note that [[hCalendar]] was created as a 1:1 html version of iCalendar, a ''collection'' of events; microformats2's [[h-event]] is for a ''single'' event. If we go with a feed of events, we should revive the iCalendar idea. We need to give it a name that makes it clear it's a feed of events. Perhaps '''h-feed-events'''? [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:15, 21 February 2021 (UTC)

There are GitHub issues arguing against me and for broadening [[h-feed]]'s use:
* https://github.com/microformats/h-feed/issues/3
* https://github.com/microformats/h-entry/issues/16
So that might be the way to go. I still think we need a way to determine that the feed specifies opening hours, perhaps with a p-children-type for h-feed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 20:11, 21 February 2021 (UTC)

I don't understand how the <code>id</code> attributes and url fragment urls are supposed to work. The fragment urls link to their own p containers. Is that supposed to convey that this is a repeating event? [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:27, 21 February 2021 (UTC)

=== simple class proposal ===
proposed format:

<nowiki><span class="operating-hours">
Tu-Sa 08:00-15:00; Sa 08:00-12:00
</span></nowiki>

see it here: http://www.geodatacheck.com/p/2

Use a semicolon to separate the different days or or time ranges.
Use two letter english day names. Times are local times with leading zero

This is the format as used in openstreetmap.org for a node description with opening hours. Openstreetmap has very rigid semantics, so it makes sense to follow their format.
There are several issues with proposal:
<div class="issues discussion">
* '''citation needed''' - please provide a link to where Openstreetmap defines this format on the [[opening-hours-formats]] page. - [[User:Tantek|Tantek]] 18:08, 21 December 2012 (UTC)
* no real world use case. how would such a microformat help users? this should be documented in the introduction to an [[opening-hours]] effort. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* proposal is 'a priori' - that is proposal has been made without documentation of real world examples per the [[process]]. please document real world [[examples]] of pages that would benefit from this markup so we can design the format only for their needs and no more. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* did not research previous formats. we have no idea if this effort is reinventing various wheels or not. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* uses new datetime formats, e.g. "Tu-Sa". Is there some way to re-use ISO8601 instead? - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)
* not international, e.g. "Tu-Sa". this could be addressed with ISO8601 usage instead. - [[User:Tantek|Tantek]] 21:17, 21 February 2011 (UTC)

I don't see anything in [https://www.iso.org/iso-8601-date-and-time-format.html ISO 8601] to specify days of the week. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 17:02, 16 December 2020 (UTC)
</div>

=== Operating Hours Brainstorming ===
:This section was merged from [[operating-hours]]

This section documents a method that can be used to mark up the operating hours of stores, restaurants, museums, offices, and other establishments that have set hours and are open on a regular basis. This is based on the [[hCalendar]] microformat.

==== Discussion Participants ====
===== Authors =====
* [http://dragotown.com Nick Drago]
* [http://suda.co.uk/ Brian Suda]

===== Contributors =====

==== Introduction ====
This effort came about as a result of the need for a human and machine readable markup format that can be used to define the operating hours of establishments.

Stores, businesses, etc. often provide their operating hours on their websites. With the addition of a small bit of markup, they are able to define their operating hours on their websites in such a way that spiders and other aggregators can retrieve such hours, automatically convert them to the iCalendar format, and use this data in any iCalendar application or service.

==== Using RRULE in hCalendar ====
This was suggested [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008562.html] by Brian. Is this the most appropriate method? --Nick

<pre>
// example definition of operating hours using RRULE in hCalendar

<h1>Pardon the Interruption</h1>
<p class="vevent">
<a class="url uid summary"
href="http://sports.espn.go.com/...">Pardon the Interruption</a>
is a <span class="category">TV</span> <span
class="category">sports</span> show.
<abbr class="dtstart" title="2001-10-22">It airs</abbr>
<span class="rrule">
<span class="freq">weekly</span>
<abbr class="byday" title="mo,tu,we,th,fr">Monday to
Friday</abbr> at <abbr class="byhour" title="5">5:30pm</abbr>
</span>


<abbr class="tzid" title="US-Eastern">ET</abbr> on ESPN.

The hosts of the show are longtime friends
<span class="hcard">
<span class="fn n">
<span class="given-name">Tony</span>
<span class="family-name">Kornheiser</span>
</span>
</span>
and ... (hCard for Michael Wilbon not shown)
<span class="description">They discuss - and frequently argue over
- the top stories of the
day in "sports... and other stuff".</span>
</p>
</pre>

==== References ====
===== Normative References =====
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[hcard]]
* [[hCalendar]]
* [http://www.ietf.org/rfc/rfc2445.txt iCalendar RFC2445]
* [http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html ISO 8601]

===== Informative References =====
* [http://en.wikipedia.org/wiki/ISO_8601 Wikipedia article on ISO 8601]
* [http://www.xfront.com/microformats/hCalendar_part2.html Tutorial on recurring events in hCalendar]

===== Related =====
* [[operating-hours-examples]]
* [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008562.html Corresponding thread from uf-discuss]

== related ==
* [[opening-hours]]
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== see also ==
* [[hCard]]
* [[hCalendar]]

opening-hours-brainstorming

2021-02-21T20:11:04Z

Btrem: /* Jacky's Idea for Rendering a Week of Hours */ Adds links to GitHub issues suggesting broader use of h-feed.

opening-hours-brainstorming

2021-02-21T18:27:26Z

Btrem: /* Jacky's Idea for Rendering a Week of Hours */ Asks for clarification of fragment url usage.

opening-hours-brainstorming

2021-02-21T18:15:55Z

Btrem: /* Jacky's Idea for Rendering a Week of Hours */ Suggests a new h-event collection container.

opening-hours-brainstorming

2021-02-20T02:38:11Z

Btrem: /* calendar of unnamed events */ suggests a type for opening hours

{{stub}}

Per [[process]] this page is for developing a microformat to markup restaurant menus as published on the web, for consumption by services that may provide various services such as [[food]] delivery.
* [[menu-examples]]
* [[menu-formats]]
* [[menu-brainstorming]]

Most restaurants publish menus on their own websites. Many also publish them on third party sites (delivery services like Door Dash, reservation sites like Open Table, etc.), which often requires reentering the same data in several places. And menus are often out of sync between different websites. A microformat for menus could help solve, or at least alleviate, this problem.

== See Also ==
* [[food]]

include-pattern-brainstorming

2020-12-22T04:47:16Z

Btrem: /* Use data element */ Points out problem with data semantics and include pattern.

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
<p>We have three branches in <span class="locality" id="ldn">London</span>,
including our head office in <span class="locality" id="ken">Kensington</span>:</p>
<ul>
<li class="adr #ldn">
<span class="street-address">123 Oxford Street</span>
</li>
<li class="adr #ken #ldn">
<span class="street-address">5 Kensington High Street</span>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a <span> element) where the included content should go:

<pre>
<p>Our head office is in <span id="ldn" class="locality">London</span> at:
<p class="adr">
<span class="street-address">5 Kensington High Street</span><br>
<span class="#ldn"></span>
<span class="postal-code">SW7 1AA</span>
</p>
</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre><span class="vcard">
<span class="data">
<span class="fn">Foo</span>
</span>
<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</span></pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre><span class="vcard">
<span class="include data"></span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

The result "could" turn out much like this:

example,
<pre><span class="vcard">
<span class="fn">Foo</span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr"><span class="street-address">665 3rd Street</span>, and</li>
<li id="adr2" class="adr"><span class="street-address">123 Folsom</span></li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has <span id="#adrlist1>office locations in <span class="locality">San Francisco</span></span>:
<a id="adr1" href="#adrlist1" rel="group" class="adr"><span class="street-address">665 3rd Street</span><span>,
and <a id="adr2" href="#adrlist1" rel="group" class="adr"><span class="street-address">123 Folsom</span></span>
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

=== Use html5 custom element ===
An include pattern could use a [https://html.spec.whatwg.org/dev/custom-elements.html custom html5 element] without any semantics, perhaps <code><mf-include></code>, with a custom attribute <code>includeid</code>. This custom attribute would work similar to how the standard <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute works. Authors could place a space-separated list of tokens in <code>includeid</code>. A microformats parser would then search the document for an element whose <code>id</code> matches one of those tokens, and include that matched element in the microformats element's sub-tree as if it appeared in that part of the DOM. Here's the first example on this page, marked up with the custom element instead of the class-based solution.

<pre>
<p>We have three branches in <span id="ldn">London</span>,
including our head office in <span id="ken">Kensington</span>:</p>
<ul>
<li class="adr">
<span class="street-address">123 Oxford Street</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
<li class="adr">
<span class="street-address">5 Kensington High Street</span>
<mf-include class="locality" includeid="ken ldn"></mf-include>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
</ul>
</pre>

There's a [https://btrem.github.io/microformats/include-pattern/ full write up of this idea] with links to two pages showing how this include pattern might work with the h-recipe format. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:24, 14 December 2020 (UTC)

=== Use html5 itemref attribute ===
Of course, since the [[include-pattern-brainstorming#Use_html5_custom_element|custom element idea]] is essentially based on html5's <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute, we could just use that attribute and call it good. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:41, 14 December 2020 (UTC)

See earlier [[microformats2-brainstorming#adopt_itemref]] which proposed considering itemref for include-pattern use-cases.

=== Use <code>data</code> element ===
An include pattern could use the [[html5]] <code>data</code> element.
<pre>
<p>We have three branches in <span id="ldn">London</span>,
including our head office in <span id="ken">Kensington</span>:</p>
<ul>
<li class="adr">
<span class="street-address">123 Oxford Street</span>
<data class="locality include" value="ldn"></data>
</li>
<li class="adr">
<span class="street-address">5 Kensington High Street</span>
<data class="locality include" value="ken ldn"></data>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
<data class="locality include" value="ldn"></data>
</li>
</ul>
</pre>

This example would find elements with an id that matches a token in the <code>value</code> attribute and include them inside the <code>data</code> tags. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 03:15, 22 December 2020 (UTC)

The problem with this approach is that it violates the semantics of the [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/data data element]: "The HTML <data> element links a given piece of content with a machine-readable translation." The use suggested in this section does not provide a machine readable version of the content, because there is no content. The markup could be changed to include content in the <code>data</code> element, and in some cases this might be desirable as fallback, but even in such cases, it's hard to see how that content is related to the <code>value</code> attribute. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 04:47, 22 December 2020 (UTC)

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:Guillaume Lebleu|Guillaume Lebleu]]

== Related Pages ==
{{include-pattern-related-pages}}

include-pattern-brainstorming

2020-12-22T03:15:02Z

Btrem: Adds proposal to use html5 data element.

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
<p>We have three branches in <span class="locality" id="ldn">London</span>,
including our head office in <span class="locality" id="ken">Kensington</span>:</p>
<ul>
<li class="adr #ldn">
<span class="street-address">123 Oxford Street</span>
</li>
<li class="adr #ken #ldn">
<span class="street-address">5 Kensington High Street</span>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a <span> element) where the included content should go:

<pre>
<p>Our head office is in <span id="ldn" class="locality">London</span> at:
<p class="adr">
<span class="street-address">5 Kensington High Street</span><br>
<span class="#ldn"></span>
<span class="postal-code">SW7 1AA</span>
</p>
</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre><span class="vcard">
<span class="data">
<span class="fn">Foo</span>
</span>
<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</span></pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre><span class="vcard">
<span class="include data"></span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

The result "could" turn out much like this:

example,
<pre><span class="vcard">
<span class="fn">Foo</span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr"><span class="street-address">665 3rd Street</span>, and</li>
<li id="adr2" class="adr"><span class="street-address">123 Folsom</span></li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has <span id="#adrlist1>office locations in <span class="locality">San Francisco</span></span>:
<a id="adr1" href="#adrlist1" rel="group" class="adr"><span class="street-address">665 3rd Street</span><span>,
and <a id="adr2" href="#adrlist1" rel="group" class="adr"><span class="street-address">123 Folsom</span></span>
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

=== Use html5 custom element ===
An include pattern could use a [https://html.spec.whatwg.org/dev/custom-elements.html custom html5 element] without any semantics, perhaps <code><mf-include></code>, with a custom attribute <code>includeid</code>. This custom attribute would work similar to how the standard <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute works. Authors could place a space-separated list of tokens in <code>includeid</code>. A microformats parser would then search the document for an element whose <code>id</code> matches one of those tokens, and include that matched element in the microformats element's sub-tree as if it appeared in that part of the DOM. Here's the first example on this page, marked up with the custom element instead of the class-based solution.

<pre>
<p>We have three branches in <span id="ldn">London</span>,
including our head office in <span id="ken">Kensington</span>:</p>
<ul>
<li class="adr">
<span class="street-address">123 Oxford Street</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
<li class="adr">
<span class="street-address">5 Kensington High Street</span>
<mf-include class="locality" includeid="ken ldn"></mf-include>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
</ul>
</pre>

There's a [https://btrem.github.io/microformats/include-pattern/ full write up of this idea] with links to two pages showing how this include pattern might work with the h-recipe format. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:24, 14 December 2020 (UTC)

=== Use html5 itemref attribute ===
Of course, since the [[include-pattern-brainstorming#Use_html5_custom_element|custom element idea]] is essentially based on html5's <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute, we could just use that attribute and call it good. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:41, 14 December 2020 (UTC)

See earlier [[microformats2-brainstorming#adopt_itemref]] which proposed considering itemref for include-pattern use-cases.

=== Use <code>data</code> element ===
An include pattern could use the [[html5]] <code>data</code> element.
<pre>
<p>We have three branches in <span id="ldn">London</span>,
including our head office in <span id="ken">Kensington</span>:</p>
<ul>
<li class="adr">
<span class="street-address">123 Oxford Street</span>
<data class="locality include" value="ldn"></data>
</li>
<li class="adr">
<span class="street-address">5 Kensington High Street</span>
<data class="locality include" value="ken ldn"></data>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
<data class="locality include" value="ldn"></data>
</li>
</ul>
</pre>

This example would find elements with an id that matches a token in the <code>value</code> attribute and include them inside the <code>data</code> tags. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 03:15, 22 December 2020 (UTC)

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:Guillaume Lebleu|Guillaume Lebleu]]

== Related Pages ==
{{include-pattern-related-pages}}

menu-brainstorming

2020-12-18T19:38:32Z

Btrem: Adds idea for menu sections with section element.

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 16:31, 4 December 2020 (UTC)

Ideas for property names:
* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
** p-organization - very adaptable, but not very intuitive.
** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:57, 16 December 2020 (UTC)

There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:42, 16 December 2020 (UTC)

Another idea for menu sections is to use the <code>section</code> element without any class name. A nested <code>hx</code> element would name the menu section ("appetizers", "dinner", etc.). It has the advantage of being native html5 and understood by or at least intuitive to authors. There are, however drawbacks. One is that it would require <code>section</code> where it is not convenient. One example is a menu using table markup, where sections are delimited by the <code>tbody</code> element. That could work with <code>th</code> standing in for <code>hx</code>, but that might be confusing. Probably not workable, but worth mentioning. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 19:38, 18 December 2020 (UTC)

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

{{stub}}

Per [[process]] this page is for developing a microformat to markup restaurant menus as published on the web, for consumption by services that may provide various services such as [[food]] delivery.
* [[menu-examples]]
* [[menu-formats]]
* [[menu-brainstorming]]

Most restaurants publish menus on their own websites. Many also publish their menus on third party sites (delivery services like Door Dash, reservation sites like Open Table). A microformat for menus could help solve, or at least alleviate, this problem.

== See Also ==
* [[food]]

menu-brainstorming

2020-12-16T22:42:01Z

Btrem: Added signature.

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 16:31, 4 December 2020 (UTC)

Ideas for property names:
* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
** p-organization - very adaptable, but not very intuitive.
** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:57, 16 December 2020 (UTC)

There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:42, 16 December 2020 (UTC)

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

menu-brainstorming

2020-12-16T22:10:36Z

Btrem: Adds suggestion for availability property.

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 16:31, 4 December 2020 (UTC)

Ideas for property names:
* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
** p-organization - very adaptable, but not very intuitive.
** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:57, 16 December 2020 (UTC)

There should be a way for publishers to indicate menu availability, so perhaps we should include a p-availability property. It would be nice if that could embed a machine readable format, but it doesn't look like there's been much work on [[opening-hours]]. Minus my contribution to earlier today, there hasn't been any contributions since 2017.

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

menu-examples

2020-12-16T21:59:52Z

Btrem: /* third party services */ Adds Toast Tab POS.

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] have a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The [https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus in the United States. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

==== Toast Tab ====
Toast Tab is a restaurant <abbr title="point of sales>P.O.S.</abbr> system. It offers an online ordering for pickup service that publishes the restaurant's menu. Since Toast Tab is publishing from the restaurant's POS system -- i.e., the same system that employees use to enter an order for patrons in the restaurant -- their menus are likely to be accurate.

=== menu duplication ===
Many restaurants publish their menu on more than one site, usually because they subscribe to a third party service which copies their menu for the convenience of that service's customers. At minimum, this entails reentering data. Often, the menus are out of sync.

==== The Sitting Room ====
The Sitting Room is a wine bar in Seattle, Washington, United States.
* [https://www.the-sitting-room.com/food restaurant website menu]
* [https://www.yelp.com/biz_photos/the-sitting-room-seattle?select=dRxYnz9hzLQ4o-VZ1yTPSg photo of menu on Yelp]
* [https://www.toasttab.com/thesittingroom/v3 Toast Tab menu]
* [https://www.opentable.com/restaurant/profile/206647 Open Table menu]
* [https://www.tripadvisor.com/Restaurant_Review-g60878-d432572-Reviews-The_Sitting_Room-Seattle_Washington.html Trip Advisor menu]
These five urls appear to contain three different menus:
# Trip Advisor and Open Table
# Sitting Room (i.e. their own website) and Toast Tab
# Yelp

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

menu-examples

2020-12-16T21:53:29Z

Btrem: Adds section on menu duplication with one example.

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] have a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The [https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus in the United States. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

=== menu duplication ===
Many restaurants publish their menu on more than one site, usually because they subscribe to a third party service which copies their menu for the convenience of that service's customers. At minimum, this entails reentering data. Often, the menus are out of sync.

==== The Sitting Room ====
The Sitting Room is a wine bar in Seattle, Washington, United States.
* [https://www.the-sitting-room.com/food restaurant website menu]
* [https://www.yelp.com/biz_photos/the-sitting-room-seattle?select=dRxYnz9hzLQ4o-VZ1yTPSg photo of menu on Yelp]
* [https://www.toasttab.com/thesittingroom/v3 Toast Tab menu]
* [https://www.opentable.com/restaurant/profile/206647 Open Table menu]
* [https://www.tripadvisor.com/Restaurant_Review-g60878-d432572-Reviews-The_Sitting_Room-Seattle_Washington.html Trip Advisor menu]
These five urls appear to contain three different menus:
# Trip Advisor and Open Table
# Sitting Room (i.e. their own website) and Toast Tab
# Yelp

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

opening-hours-formats

2020-12-16T18:25:35Z

Btrem: Adds section for schema.org's opening hours type and properties.

{{DISPLAYTITLE:opening hours formats}}

This is part of an effort per the microformats [[process]] to research, gather examples, and brainstorm for a microformat for marking up the [[opening-hours]] for a business or organization.
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

== OpenStreetMap ==
OpenStreetMap allows venues to be tagged with the [https://wiki.openstreetmap.org/wiki/Opening_hours <var>opening_hours</var>] tag. The value of this tag has been formalized and is defined in the [http://www.netzwolf.info/en/cartography/osm/time_domain/ TimeDomain specification], where there is also a JavaScript implementation.

[http://wiki.openstreetmap.org/wiki/Key:opening_hours Key:opening_hours] is also defined on the OSM Wiki.

The same string-based format is used to mark the times of religious services in places of worship using the [https://wiki.openstreetmap.org/wiki/Key:service_times <var>service_times</var>] tag, the times of collections from post boxes with the [https://wiki.openstreetmap.org/wiki/Key:collection_times <var>collection-times</var>] tag, and there is a proposal to mark venues which allow smoking (possibly in a separate area) with the [https://wiki.openstreetmap.org/wiki/Key:smoking_hours <var>smoking_hours</var>] tag, and also with the 'lit' tag to specify when a feature (e.g. building) is lit up.

A broader proposal also exists for using the <var>opening_hours</var> format for describing [https://wiki.openstreetmap.org/wiki/Conditional_restrictions conditional restrictions], for instance roads that have speed limits that vary depending on time of day, and roads that allow only specific types of traffic (buses and bicycles, for instance) during periods of the day.

Comments can also be added in quotations.

Examples:

* Tu-Su 08:00-15:00;Sa 08:00-12:00 – see [http://www.openstreetmap.org/browse/node/624582426 node:624582426], a cafe in Terlizzi, Italy.

== Google maps display ==
Google places uses this format to *display* the opening hours, and then applies some javascript to hide the lines which are not immediately useful:
The translate the day names and the time formats into the users locale.

This is clearly rendered data for end user consumption and not a format one can use to establish a standard.

See an example here with opening hours: http://maps.google.com/maps/place?cid=17374953169507020841

<source lang=html4strict>
<table style="" id="oh-ov-table" class="oh-table">
<tbody>
<tr class="oh-highlight-day">
<td class="oh-day">
Montag
</td>
<td dir="ltr">
11:00-16:00
</td>
</tr>
<tr>
<td class="oh-day">
Dienstag
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Mittwoch
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Donnerstag
</td>
<td dir="ltr">
11:00-22:00
</td>
</tr>
<tr>
<td class="oh-day">
Freitag
</td>
<td dir="ltr">
11:00-16:00
</td>
</tr>
<tr>
<td class="oh-day">
Samstag
</td>
<td dir="ltr">
Geschlossen
</td>
</tr>
<tr>
<td class="oh-day">
Sonntag
</td>
<td dir="ltr">
Geschlossen
</td>
</tr>
</tbody>
</table>
</source>

== schema.org ==
=== opening hours property===
schema.org has an [https://schema.org/openingHours opening hours] <dfn>property</dfn>. Days are specified with two letter abbreviations, e.g. <abbr title="Monday">Mo</abbr>, <abbr title="Tuesday">Tu</abbr>, etc.; days can be comma separated for separate days or a range can be specified with a range. Times are specified in 24 hour format. Examples:
<pre>
<data lang="en" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Open Monday, Wednesday, Friday 9am-1pm</data>
</pre>
<pre>
<data lang="en" itemprop="openingHours" value="Mo-Fr 09:00-13:00">Open Monday-Friday 9am-1pm</data>
</pre>
<pre>
<data lang="fr" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Disponible lundi, mercredi, vendredi 9:00-13:00</data>
</pre>
<pre>
<data lang="de" itemprop="openingHours" value="Mo,We,Fr 09:00-13:00">Montag, Mittwoch, Freitag 9:00-13:00</data>
</pre>

Note: the examples from the [https://schema.org/openingHours schema website] use the <code>content</code> attribute on the <code>p</code> element. This does not appear to be allowed in [https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes html]. These examples were changed to use the <code>data</code> element with the <code>value</code> attribute.

=== opening hours type ===
There is also a [https://schema.org/OpeningHoursSpecification Opening Hours Specification] <dfn>type</dfn>, which can use the opening hours property along with more granular properties to specify exceptions, e.g., "open 9-6 except on New Year's Day." This type has a more complex syntax. There is a dayOfWeek property that uses a url to specify the day, e.g. https://schema.org/Tuesday. There are separate properties for opens and closes. Example:

<pre>
<p>Opening hours</p>
<p itemprop="openingHoursSpecification" itemscope itemtype="https://schema.org/OpeningHoursSpecification">
<span itemprop="dayOfWeek" href="https://schema.org/Monday">Monday</span>
<time itemprop="opens" content="09:00">9:00 AM</time> - <time itemprop="closes" content="17:00">5:00 PM</time>
</p>
<p itemprop="openingHoursSpecification" itemscope itemtype="https://schema.org/OpeningHoursSpecification">
<span itemprop="dayOfWeek" href="https://schema.org/Tuesday">Tuesday</span>
<time itemprop="opens" content="09:00:00">9:00 AM</time> - <time itemprop="closes" content="17:00:00">5:00 PM</time>
</p>
</pre>

== see also ==
* [[opening-hours]]
* [[opening-hours-examples]]
* [[opening-hours-formats]]
* [[opening-hours-brainstorming]]

opening-hours-brainstorming

2020-12-16T17:02:41Z

Btrem: /* simple class proposal */ Adds not that iso8601 lacks dow support.

irc

2020-12-16T02:47:37Z

Btrem: /* Cross-platform */ Removes link to chatzilla extension which is no longer available.

{{DISPLAYTITLE:#microformats on freenode}}
{{TOC-right}}
;shortURL
:http://ufs.cc/w/irc

== Quick Start ==
You may use a IRC client application such as [http://colloquy.info/ Colloquy] (Mac or iOS) or [https://market.android.com/details?id=org.yaaic&feature=search_result Yaaic on Android] to join:
* irc://irc.freenode.net/microformats

Alternatively you may use a browser to quickly join and chat:
* http://webchat.freenode.net/?channels=microformats&nick=uf-wiki-visitor



The microformats IRC channel is hosted on the freenode.net server. See [[irc#Joining_a_server_and_channel|Joining a server and channel]] help for further information and use of client applications which provide additional services (authenticated nicknames, logging, etc.).

== Logs ==
Recent logs of the Freenode #microformats IRC channel can be found at:
* https://chat.indieweb.org/microformats/
* [http://logbot.glob.com.au/?c=freenode%23microformats&s=today logbot.glob.com.au microformats IRC Logs]

Older logs can be found at the following locations for the following periods:
* [https://chat.indieweb.org/microformats/2011-02-12 2011-02-12]–[https://chat.indieweb.org/microformats current] at https://chat.indieweb.org/microformats
* [http://logbot.glob.com.au/?c=freenode%23microformats&s=20090220&e=20090220 2009-02-20] - [http://logbot.glob.com.au/?c=freenode%23microformats&s=today current] at [http://logbot.glob.com.au/?c=freenode%23microformats&s=today logbot.glob.com.au microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20131028 2013-10-28] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/ current] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
----
* [http://krijnhoetmer.nl/irc-logs/microformats/20130811 2013-08-11] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/20130917 2013-09-17] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20120726 2012-10-09] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/20130807 2013-08-07] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20120726 2012-07-26] - [http://krijnhoetmer.nl/irc-logs/microformats/20120916 2012-09-16] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20090220 2009-02-20] - [http://krijnhoetmer.nl/irc-logs/microformats/20120621 2012-06-21] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2011-04-05 2011-04-05] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2011-02-24 2011-02-24] - [http://rbach.priv.at/Microformats/IRC/2011-03-03 2011-03-03] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2009-08-28 2009-08-28] - [http://rbach.priv.at/Microformats/IRC/2010-09-27 2010-09-27] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2009-03-26 2009-03-26] - [http://rbach.priv.at/Microformats/IRC/2009-06-29 2009-06-29] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* 2009-02-09 - 2009-02-20 '''missing'''. if anyone has any logs for this time period, please upload them and add links here.
* [http://rbach.priv.at/Microformats/IRC/2009-01-14 2009-01-14] - [http://rbach.priv.at/Microformats/IRC/2009-02-09 2009-02-09] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20080825 2008-08-25] - [http://krijnhoetmer.nl/irc-logs/microformats/20090114 2009-01-14] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* 2008-08-16 - 2008-08-24 '''missing'''. if anyone has any logs for this time period, please upload them and add links here.
* [http://rbach.priv.at/Microformats/IRC/2005-11-16 2005-11-16] - [http://rbach.priv.at/Microformats/IRC/2008-08-16 2008-08-16] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]

Until sometime on 2007-07-16, there was an [http://microformat.makedatamakesense.com/log_feed/ atom feed] provided for the [http://rbach.priv.at/Microformats-IRC/ rbach IRC Logs].

=== logs status ===
* [http://logbot.glob.com.au/?c=freenode%23microformats logbot.glob.com.au microformats IRC Logs] are current and live
* [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs] appears to have stopped logging as of 2016-01.
** I emailed and heard back from Krijn on 2016-03-19 "Yeah, sorry, I know, server resources are very low for that (old) machine. I think it's sort of EOL.." [http://logs.glob.uno/?c=freenode%23microformats&s=21+Mar+2016&e=21+Mar+2016&h=Krijn#c86411] -- gRegor
* [http://rbach.priv.at/Microformats-IRC/ rbach IRC Logs] appear to have stopped logging as of 2009-06-29.

== People on IRC ==
See our [[irc-people|list of IRC regulars]] and their normal timezones.

Our channel has regular admins, who are also mailing list and wiki admins. If you want to get their attention, just say "adminhelp".

==Bots on IRC==
The IRC channel uses these bots:
* [[Loqi]] - logs IRC, posts notifications to IRC of wiki edits
** If Loqi is missing, see https://indieweb.org/Loqi for instructions
** If Wiki edits are missing, ask an admin for "adminhelp", and reference [[admin-how-to#irc]]

=== Previous Bots ===
These bots were active ~2005-2009? (actual dates can likely be confirmed by checking old IRC logs)
* [[mfbot]] - logs all edits to this wiki. (Contact: [[User:RyanKing|Ryan King]])
* [[mflogbot]] - logs the irc channel itself to archives on the web. (Contact: [[User:RobertBachmann|Robert Bachmann]])
* [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot]

==== Greeting Bot ====
To display a brief description of who you are each time you join the channel, you can use “JiBot” to create a definition for your username. To do so pass the <tt>?def</tt> command using something like the following convention (be brief):

<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.example.com</nowiki></code>

More information about using JiBot commands can be found on the [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot website]

== Getting started with IRC ==
'''Please note:''' These directions relate specifically to the services that [http://freenode.net/ Freenode] offers. Other IRC servers may differ with the services they offer and how to operate them.

===Joining a server and channel===
Most clients will offer you a connection dialogue showing the required fields for connection. The details to connect to the server are:

*Server: <code>irc.freenode.net</code>
*Port: <code>6667</code> (usually default)

You should also fill in any fields to set your alias, real name and email address. If available, save these settings for later to speed up connecting in future.

More on setting a password protected alias can be [[irc#Creating_a_registered_nickname|read here]].

Once connected, you will most likely be presented with the "MOTD" (message of the day). For the first visit, it is advisable to read this to find out about the server's policies and other important pieces of news and help, otherwise it can be ignored and you can either [[irc#Creating_a_registered_nickname|authenticate your alias]] or join a channel.

Your client may display to you a listing of all available channels. Locate <code>#microformats</code> and select to join, or type <code>'''/join #microformats'''</code> into the command line available to you in your client (where you've just been shown your connection).

Assuming you've connected correctly, you should now find youself in the microformats channel!

More detailed, but general, advice can be [http://www.irchelp.org/irchelp/irctutorial.html#intro read here].

===Creating a registered nickname===
Registration means that a password becomes associated with your alias/nickname/sign-in name and from the point of registration authorisation is required to communicate using that alias.

Registration of a nickname is required for some channels, and should be done to protect your identity.

To register with [http://freenode.net Freenode], you must communicate with their service known as NickServ. The two basic command you will need to get started are:

For registration: <code>/msg nickserv register ''password''</code>

For authentication (login): <code>/msg nickserv identify ''password''</code>

With <code>''password''</code> being a value of your choice. You can also associate an email address with your nickname, which is optional, but advisable, should you want to request a password retrieval:

To add your email address: <code>/msg nickserv set email ''email''</code>

Where <code>''email''</code> is your email address.

Your client may offer you an option to set your alias and password, so that you will not have to manually enter this information on each join. Refer to your client's help files for more on this.

These commands can be typed directly into the server window upon join, or whilst in a channel, just as you would normally send a message.

More detailed user registration command information can be found in [http://freenode.net/faq.shtml#userregistration Freenode's FAQ]

===Communicating===
Sending a message to a channel may be as simple as joining the channel and typing into the window, just as you would with an Instant Messenger. You can refer to your client's help files for quicker/alternative methods of doing the following. For all clients the following commands are available (the parts in bold must be used, but are not seen by others):

'''Sending a message to the entire channel you are currently in:'''

Command: <kbd>'''/msg''' Hello world!</kbd>

Result: <samp><Bill> Hello world!</samp>

'''Sending an action/emotive/3rd person statement:'''

Command: <kbd>'''/me''' dances a code jig</kbd>

Result: <samp>Bill dances a code jig</samp>

'''Sending a message to one person only (private chat):'''

Command: <kbd>'''/msg Bob''' Hi, would you like to code jig?</kbd>

Result (for Bob only): <samp><Bill> Hi, would you like to code jig?</samp>

==Clients==
The following clients are recommended by #microformats participants:

=== Web ===
* [http://leafychat.com/#microformats@irc.freenode.net Leafy Chat]

===Windows===
* [http://www.mirc.com/ mIRC] — Popular Windows client. Trial version only.
* [http://xchat.org/ X-Chat] — Popular cross-platform client. [http://www.silverex.org/download/ Free Windows version] available.
* [http://www.adiirc.com/ AdiIRC] — Simple C# based IRC client.
* [http://www.miranda-im.org/ Miranda] — Lightweight, muti-protocol instant messenger.

=== Mac ===
* [http://colloquy.info Colloquy] — open source, free
* [http://homepage.mac.com/philrobin/conversation/ Conversation]
* [http://sourceforge.net/projects/fire Fire] — open source, free
* [http://www.conceitedsoftware.com/products/linkinus Linkinus]
* [http://www.chipersoft.com/minerva/ Minerva]
* [http://www.snak.com/ Snak]
* [http://xchataqua.sourceforge.net/twiki/bin/view/Main/WebHome X-Chat Aqua]
** now has [http://www.portableapps.org PortableApps] version — [http://www.macupdate.com/info.php/id/21685/portable-x-chat-aqua MacUpdate link]
* [http://www.aquaticx.com/ Xirc]

===Cross-platform===
* [http://pidgin.im/ Pidgin] — Popular open-source multi-protocol windows client, using libpurple
* [http://irssi.org/ Irssi] — Unix client, often run from a shell, sometimes [http://f0rked.com/articles/irssi in conjunction with 'screen'].
* [http://jirc.hick.org/jirc/ jIRCii]

== meetups ==
The idea of having IRC meetups (a set time for a meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups.

==IRC and microformats==
=== hCard ===
<div class="discussion">
* ''How do we maintain info about ircing in our hCards (nick, network, fav-channels?)?''
** presumably this would be done with a URL. - [[User:Tantek|Tantek]] 18:42, 30 July 2009 (UTC)
</div>

== Related discussions ==
* [[chat]] [[chat-examples|chat examples]], [[chat-formats|chat formats]], and [[chat-brainstorming|chat brainstorming]]

==See also==
*[[irc-meetups]]
*[[discuss|Other discussion fora]]

irc

2020-12-16T02:44:03Z

Btrem: Removes link to Chatzilla, which is no longer available according to addons.mozilla.org.

{{DISPLAYTITLE:#microformats on freenode}}
{{TOC-right}}
;shortURL
:http://ufs.cc/w/irc

== Quick Start ==
You may use a IRC client application such as [http://colloquy.info/ Colloquy] (Mac or iOS) or [https://market.android.com/details?id=org.yaaic&feature=search_result Yaaic on Android] to join:
* irc://irc.freenode.net/microformats

Alternatively you may use a browser to quickly join and chat:
* http://webchat.freenode.net/?channels=microformats&nick=uf-wiki-visitor



The microformats IRC channel is hosted on the freenode.net server. See [[irc#Joining_a_server_and_channel|Joining a server and channel]] help for further information and use of client applications which provide additional services (authenticated nicknames, logging, etc.).

== Logs ==
Recent logs of the Freenode #microformats IRC channel can be found at:
* https://chat.indieweb.org/microformats/
* [http://logbot.glob.com.au/?c=freenode%23microformats&s=today logbot.glob.com.au microformats IRC Logs]

Older logs can be found at the following locations for the following periods:
* [https://chat.indieweb.org/microformats/2011-02-12 2011-02-12]–[https://chat.indieweb.org/microformats current] at https://chat.indieweb.org/microformats
* [http://logbot.glob.com.au/?c=freenode%23microformats&s=20090220&e=20090220 2009-02-20] - [http://logbot.glob.com.au/?c=freenode%23microformats&s=today current] at [http://logbot.glob.com.au/?c=freenode%23microformats&s=today logbot.glob.com.au microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20131028 2013-10-28] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/ current] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
----
* [http://krijnhoetmer.nl/irc-logs/microformats/20130811 2013-08-11] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/20130917 2013-09-17] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20120726 2012-10-09] (partial) - [http://krijnhoetmer.nl/irc-logs/microformats/20130807 2013-08-07] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20120726 2012-07-26] - [http://krijnhoetmer.nl/irc-logs/microformats/20120916 2012-09-16] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20090220 2009-02-20] - [http://krijnhoetmer.nl/irc-logs/microformats/20120621 2012-06-21] (partial) at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2011-04-05 2011-04-05] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2011-02-24 2011-02-24] - [http://rbach.priv.at/Microformats/IRC/2011-03-03 2011-03-03] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2009-08-28 2009-08-28] - [http://rbach.priv.at/Microformats/IRC/2010-09-27 2010-09-27] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://rbach.priv.at/Microformats/IRC/2009-03-26 2009-03-26] - [http://rbach.priv.at/Microformats/IRC/2009-06-29 2009-06-29] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* 2009-02-09 - 2009-02-20 '''missing'''. if anyone has any logs for this time period, please upload them and add links here.
* [http://rbach.priv.at/Microformats/IRC/2009-01-14 2009-01-14] - [http://rbach.priv.at/Microformats/IRC/2009-02-09 2009-02-09] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]
* [http://krijnhoetmer.nl/irc-logs/microformats/20080825 2008-08-25] - [http://krijnhoetmer.nl/irc-logs/microformats/20090114 2009-01-14] at [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs]
* 2008-08-16 - 2008-08-24 '''missing'''. if anyone has any logs for this time period, please upload them and add links here.
* [http://rbach.priv.at/Microformats/IRC/2005-11-16 2005-11-16] - [http://rbach.priv.at/Microformats/IRC/2008-08-16 2008-08-16] at [http://rbach.priv.at/Microformats-IRC/ rbach microformats IRC Logs]

Until sometime on 2007-07-16, there was an [http://microformat.makedatamakesense.com/log_feed/ atom feed] provided for the [http://rbach.priv.at/Microformats-IRC/ rbach IRC Logs].

=== logs status ===
* [http://logbot.glob.com.au/?c=freenode%23microformats logbot.glob.com.au microformats IRC Logs] are current and live
* [http://krijnhoetmer.nl/irc-logs/microformats krijnhoetmer microformats IRC Logs] appears to have stopped logging as of 2016-01.
** I emailed and heard back from Krijn on 2016-03-19 "Yeah, sorry, I know, server resources are very low for that (old) machine. I think it's sort of EOL.." [http://logs.glob.uno/?c=freenode%23microformats&s=21+Mar+2016&e=21+Mar+2016&h=Krijn#c86411] -- gRegor
* [http://rbach.priv.at/Microformats-IRC/ rbach IRC Logs] appear to have stopped logging as of 2009-06-29.

== People on IRC ==
See our [[irc-people|list of IRC regulars]] and their normal timezones.

Our channel has regular admins, who are also mailing list and wiki admins. If you want to get their attention, just say "adminhelp".

==Bots on IRC==
The IRC channel uses these bots:
* [[Loqi]] - logs IRC, posts notifications to IRC of wiki edits
** If Loqi is missing, see https://indieweb.org/Loqi for instructions
** If Wiki edits are missing, ask an admin for "adminhelp", and reference [[admin-how-to#irc]]

=== Previous Bots ===
These bots were active ~2005-2009? (actual dates can likely be confirmed by checking old IRC logs)
* [[mfbot]] - logs all edits to this wiki. (Contact: [[User:RyanKing|Ryan King]])
* [[mflogbot]] - logs the irc channel itself to archives on the web. (Contact: [[User:RobertBachmann|Robert Bachmann]])
* [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot]

==== Greeting Bot ====
To display a brief description of who you are each time you join the channel, you can use “JiBot” to create a definition for your username. To do so pass the <tt>?def</tt> command using something like the following convention (be brief):

<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.example.com</nowiki></code>

More information about using JiBot commands can be found on the [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot website]

== Getting started with IRC ==
'''Please note:''' These directions relate specifically to the services that [http://freenode.net/ Freenode] offers. Other IRC servers may differ with the services they offer and how to operate them.

===Joining a server and channel===
Most clients will offer you a connection dialogue showing the required fields for connection. The details to connect to the server are:

*Server: <code>irc.freenode.net</code>
*Port: <code>6667</code> (usually default)

You should also fill in any fields to set your alias, real name and email address. If available, save these settings for later to speed up connecting in future.

More on setting a password protected alias can be [[irc#Creating_a_registered_nickname|read here]].

Once connected, you will most likely be presented with the "MOTD" (message of the day). For the first visit, it is advisable to read this to find out about the server's policies and other important pieces of news and help, otherwise it can be ignored and you can either [[irc#Creating_a_registered_nickname|authenticate your alias]] or join a channel.

Your client may display to you a listing of all available channels. Locate <code>#microformats</code> and select to join, or type <code>'''/join #microformats'''</code> into the command line available to you in your client (where you've just been shown your connection).

Assuming you've connected correctly, you should now find youself in the microformats channel!

More detailed, but general, advice can be [http://www.irchelp.org/irchelp/irctutorial.html#intro read here].

===Creating a registered nickname===
Registration means that a password becomes associated with your alias/nickname/sign-in name and from the point of registration authorisation is required to communicate using that alias.

Registration of a nickname is required for some channels, and should be done to protect your identity.

To register with [http://freenode.net Freenode], you must communicate with their service known as NickServ. The two basic command you will need to get started are:

For registration: <code>/msg nickserv register ''password''</code>

For authentication (login): <code>/msg nickserv identify ''password''</code>

With <code>''password''</code> being a value of your choice. You can also associate an email address with your nickname, which is optional, but advisable, should you want to request a password retrieval:

To add your email address: <code>/msg nickserv set email ''email''</code>

Where <code>''email''</code> is your email address.

Your client may offer you an option to set your alias and password, so that you will not have to manually enter this information on each join. Refer to your client's help files for more on this.

These commands can be typed directly into the server window upon join, or whilst in a channel, just as you would normally send a message.

More detailed user registration command information can be found in [http://freenode.net/faq.shtml#userregistration Freenode's FAQ]

===Communicating===
Sending a message to a channel may be as simple as joining the channel and typing into the window, just as you would with an Instant Messenger. You can refer to your client's help files for quicker/alternative methods of doing the following. For all clients the following commands are available (the parts in bold must be used, but are not seen by others):

'''Sending a message to the entire channel you are currently in:'''

Command: <kbd>'''/msg''' Hello world!</kbd>

Result: <samp><Bill> Hello world!</samp>

'''Sending an action/emotive/3rd person statement:'''

Command: <kbd>'''/me''' dances a code jig</kbd>

Result: <samp>Bill dances a code jig</samp>

'''Sending a message to one person only (private chat):'''

Command: <kbd>'''/msg Bob''' Hi, would you like to code jig?</kbd>

Result (for Bob only): <samp><Bill> Hi, would you like to code jig?</samp>

==Clients==
The following clients are recommended by #microformats participants:

=== Web ===
* [http://leafychat.com/#microformats@irc.freenode.net Leafy Chat]

===Windows===
* [http://www.mirc.com/ mIRC] — Popular Windows client. Trial version only.
* [http://xchat.org/ X-Chat] — Popular cross-platform client. [http://www.silverex.org/download/ Free Windows version] available.
* [http://www.adiirc.com/ AdiIRC] — Simple C# based IRC client.
* [http://www.miranda-im.org/ Miranda] — Lightweight, muti-protocol instant messenger.

=== Mac ===
* [http://colloquy.info Colloquy] — open source, free
* [http://homepage.mac.com/philrobin/conversation/ Conversation]
* [http://sourceforge.net/projects/fire Fire] — open source, free
* [http://www.conceitedsoftware.com/products/linkinus Linkinus]
* [http://www.chipersoft.com/minerva/ Minerva]
* [http://www.snak.com/ Snak]
* [http://xchataqua.sourceforge.net/twiki/bin/view/Main/WebHome X-Chat Aqua]
** now has [http://www.portableapps.org PortableApps] version — [http://www.macupdate.com/info.php/id/21685/portable-x-chat-aqua MacUpdate link]
* [http://www.aquaticx.com/ Xirc]

===Cross-platform===
* [https://addons.mozilla.org/en-US/firefox/addon/chatzilla/ Chatzilla] — Cross-platform IRC extension for Firefox
* [http://pidgin.im/ Pidgin] — Popular open-source multi-protocol windows client, using libpurple
* [http://irssi.org/ Irssi] — Unix client, often run from a shell, sometimes [http://f0rked.com/articles/irssi in conjunction with 'screen'].
* [http://jirc.hick.org/jirc/ jIRCii]

== meetups ==
The idea of having IRC meetups (a set time for a meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups.

==IRC and microformats==
=== hCard ===
<div class="discussion">
* ''How do we maintain info about ircing in our hCards (nick, network, fav-channels?)?''
** presumably this would be done with a URL. - [[User:Tantek|Tantek]] 18:42, 30 July 2009 (UTC)
</div>

== Related discussions ==
* [[chat]] [[chat-examples|chat examples]], [[chat-formats|chat formats]], and [[chat-brainstorming|chat brainstorming]]

==See also==
*[[irc-meetups]]
*[[discuss|Other discussion fora]]

menu-brainstorming

2020-12-16T00:57:30Z

Btrem: Adds sig to most recent addition.

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 16:31, 4 December 2020 (UTC)

Ideas for property names:
* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
** p-organization - very adaptable, but not very intuitive.
** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:57, 16 December 2020 (UTC)

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

menu-examples

2020-12-15T00:53:26Z

Btrem: /* international restaurant chains */ Specifies that nutritional info must appear on menus in the U.S.

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] have a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The [https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus in the United States. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

menu-examples

2020-12-15T00:35:35Z

Btrem: /* Benoit */ Fixes link format.

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] have a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The [https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

menu-examples

2020-12-15T00:34:25Z

Btrem: /* Break Restaurant */ Adds not about pricing multiple items by type.

Per [[process]] this page is for collecting real world [[examples]] of restaurant [[menu]] publishing, publishing information about menu items ([[food]]) intended for human consumption in an organized manner, towards the development of a menu microformat.

== Overview ==
Menus on the web have many of the same features as printed menus used in restaurants. They are a list of products organized by type. On the web, some menus include items on one page, with sections for different categories, e.g., appetizers, salads, main dishes, desserts, etc. On other sites, different menu sections are on different pages, e.g. /menu/salads, /menu/soups, etc. Some web site menus contain cocktails, either in a separate page or in its own section. Wine lists are quite common too, usually on a separate page.

There is no uniform set of category names. Some restaurants use "main dish", others denote main dish with "entree". Some use "starter", others "appetizer", to denote a first course. Also, larger menus often break up main dishes into categories, e.g., "pasta", "steak", etc. There are of course language differences, e.g., in French one finds "entrée" for first course and "plat principal" for the main dish.

== Examples ==
Example menus are organized by location.

=== France ===
French menus are sometimes organized by course instead of category, i.e., entrée (first course), plat principal (main course), and dessert. Many French restaurants offer à la carte and prix fixe menus. À la carte are structured like American menus, with individually priced items. Prix fixe menus are priced per person, with sections for each course that offer a limited number of choices.

==== Break Restaurant ====
Each item on [https://www.break-paris.fr/menus-cartes Break's menu] have a name, description, and price. Some also include tags like "<span lang="fr">Végétalien</span>" (vegan) and <span lang="fr">épicé</span> (spicy). The categories are simplified: <span lang="fr">plats</span> (plates), sides, and desserts. There is also a sections for drinks, broken up into several subsections: cocktails, wine, beer, aperitifs, etc. On some of the drink sections, each item has its own price. On several -- alcool, cocktails classiques, and cocktails création -- there is only one price printed below the heading, with that price applying to all the items beneath it.

==== Benoit ====
Benoit has two different menus. One is a [https://www.benoit-paris.com/sites/default/files/menus/2020_03_06_benoit_menu_dejeuner_fr.pdf prix fixe lunch menu] with three unnamed, implicit sections for first course, main course, and dessert. Each section offers three choices. The ]https://www.benoit-paris.com/sites/default/files/menus/2020_01_16_benoit_paris_-_carte_food_truffe_fr.pdf à la carte menu] has sections like <span lang="fr">hors d'œuvre froids</span> (cold appetizers), <span lang="fr">poissons</span> (fish), <span lang="fr">viandes</span> (meat), etc.

=== Italy ===
As in France, some Italian menus are organized by course, e.g., primo for first course, secondo for second course. Some menu sections, however, are based on a food cagegory, e.g. carne for meat, pesce for fish.

==== 'A Taverna Do' Re ====
[https://atavernadore.com/menu 'A Taverna Do' Re's menu] has 3 sections: "Antipasti", "I primi", and "La carne alla brace". The items have a long name that functions as a name-and-description, and a price.

=== United States ===

==== T.S. McHugh's Irish Pub ====
[https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf This pub menu]'s food items have a name, description, and price. Some items have two sizes (small and large) with a price for each. Also, some items contain a base price, and one or more "upsell" options with an upcharge price, e.g., nachos $8.75, add guacamole $2.00.

The draughts on the menu are organized into four categories. Each listing includes a name. The microbrew draughts include two additional pieces of information: <abbr title="international bitterness units">ibus</abbr> and <abbr title="alcohol by volume">abv</abbr>. There are also two prices (one for pint, one for pitcher) for each draught category. Those prices are listed in the heading for each category, rather than repeated in each individual listing.

==== Sal Y Limon ====
[https://www.salylimonseattle.com/menu Sal Y Limon's menu] is one page that changes when you click different categories. Each item has only a name and description, no price.

==== Canlis ====
The [https://canlis.com/menu menu at Canlis] has only name and description for each item.

==== Tavolata ====
[https://www.ethanstowellrestaurants.com/locations/tavolata-capitol-hill/takeout-menu/ Tavolata's menu] items each have a name, price, and description.

==== 99 Restaurant ====
Their menu is spread out over several pages. The menu for [https://www.99restaurants.com/menu/steak/ steaks] is a good example. Each menu item includes a name, a description, and calories. Photos of the items are linked, but not part of the initial view of the page. Also, there are no prices, presumably because the price changes by location. There are also options for many items, like adding a salad or ordering a larger portion.

==== Bertucci's ====
[https://www.bertuccis.com/menu/ Bertucci's menu] is on one page, with sections for salads, soups, entrees, etc. Each section has a picture, but individual items do not. They contain only a name, description, and price.

=== international restaurant chains ===
Large restaurants/chains must supply nutritional information on their menus. All the entries in this section show calories for each menu item.

==== Applebee's ====
They use one page, where the url changes as you scroll. Each part works the same. The [https://www.applebees.com/en/menu/sandwiches-and-more sandwiches section] to take one example has a list of items with name, picture, price, and calories, and, when you hover a mouse pointer over it, order buttons.

==== Olive Garden ====
The Olive Garden's [https://www.olivegarden.com/menu-listing/classic-entrees dinner entrees] menu (N.B. you may have to supply a location before they'll show you a menu) has a name, photo, price, and calories for each item, along with an order button, a bookmark-like "mark this as a favorite" button, and a tag if the item is "new".

=== third party services ===

==== Open Table ====
Open Table is a third party reservation site that publishes information about each restaurant that uses their service. To take one example, here's [https://www.opentable.com/ts-mchughs?originId=2&corrid=ce749341-1486-4d6c-96b4-2c4311ac6fb5&avt=eyJ2IjoyLCJtIjowLCJwIjowLCJzIjowLCJuIjowfQ&p=2020-12-03T00%3A00%3A00 T.S. McHugh's Pub on Open Table]. The menu is duplicated from [https://tsmchughs.com/wp-content/uploads/2020/06/TSs-Placemat.pdf their web site].

==== Grub Hub ====
Grub Hub is a delivery service. Like Open Table, it publishes menus for restaurants that they provide delivery for. For example, here's [https://www.grubhub.com/restaurant/sal-y-limon-10-mercer-street-seattle/1579529 Grub Hub's Sal Y Limon menu]. It has the same items as the [https://www.salylimonseattle.com/menu restaurant's own website], though the Grub Hub version includes prices.

== See Also ==
* [[menu]]
* [[menu-formats]]
* [[menu-brainstorming]]

microformats2-brainstorming

2020-12-14T23:41:26Z

Btrem: /* adopt itemref */ Adds quote about itemref from whatwg html5 spec.

Brainstorming experimental / undeveloped / rejected ideas for [[microformats-2]].

For the original brainstorming of microformats2 itself, see:
* [[microformats2-origins]]

== brainstorms to consider ==
=== document url ===
Since [[microformats2-parsing]] produces JSON with "rels" and "rel-urls", it may be useful to have a root context object which provides the URL of the document itself.

=== adopt itemref ===
There many existing real-world use-cases where either:
* several microformats in a page want to share some common data without repeating it.
** e.g. a page about a product with multiple reviews of that product (very common, products sites, Amazon/CNET et al, review aggregators, Yelp et al)
** e.g. representing the author of multiple hAtom entries on a page. Currently this is possible with the <code><address class="hcard"></code> optimisation, which would be rendered obsolete by the proposed new generic parsing rules.
* a microformat in a page needs to incorporate information spread across different parts of a page, without assigning the entire page to that microformat

The [[include-pattern]] provides the necessary functionality for existing microformats (1.0).

For 2.0 it may be reasonable to simply re-use the nice <code>itemref</code> attribute from microdata, with identical/analogous functionality.

That is, when present on the root element of a microformat, the <code>itemref</code> attribute provides a space separated list of ids of elements in the document which are then incorporated as children of the microformat, before its actual children in the document. This is a simple coarse summary of course, and the actual itemref inclusion algorithm should be followed.

Questions and possible issues:
<div class="discussion">
* Does use of 'itemref' mean requiring [[HTML5]]?
** No, <code>itemref</code> is not part of the HTML5 specification, it is currently only part of the [[microdata]] ''last call'' working draft. Thus we would be adding a "new" attribute to HTML above and beyond HTML5, though one that is already specified, and validated by current HTML validators.
* Is 'itemref' documented as a stable draft?
** 'itemref' is defined in the Last Call Working Draft of microdata. Being "last call" it has some amount of stability, but could still change before it goes to candidate recommendation (CR).
* Doesn't microformats try to avoid introducing new attributes? (e.g. from RDFa in the past).
** Yes, in general microformats try to avoid introducing new attributes. It may be ok for the set of use-cases that need "itemref". That is, they *are* a minority of actual use-cases, and thus making them use a new attribute is probably ok.
* Wouldn't it be dangerous to adopt features of separate technologies that are unstable, may change, or may disappear?
** Indeed any time we consider adopting anything from technologies in working drafts we should consider their stability and dependability on a case-by-case basis. When we do decide to re-use such technologies, we should be sure to ''copy'' their definition/functionality and provide a non-normative reference to the source, rather than normatively depend on anything that could change or disappear. In the case of 'itemref', it's been stable for a while, and if we believe the [[schema.org]] implementation announcements, there are multiple real-world implementations that surface it in common ([[search]]) user interfaces.
* Wasn't RDFa a ''stable'' augmentation of HTML, and yet we resisted incorporated attributes from it?
** In practice, no, RDFa has continued to change evolve (which is good) in response to market feedback about its complexity. There was very little real world use (and thus exercising) of RDFa until Google provided it as a Rich Snippets alternative syntax in 2009. At this point, it may be reasonable to also consider attributes from RDFa (e.g. 'vocab' instead of 'profile'), however for this particular purpose (providing inclusion functionality), the 'itemref' attribute/feature makes the most sense.

Note that itemref is only sort of part of microdata. According to the [https://html.spec.whatwg.org/multipage/microdata.html#attr-itemref whatwg html spec]:
<blockquote cite="https://html.spec.whatwg.org/multipage/microdata.html#attr-itemref">
The itemref attribute is not part of the microdata data model. It is merely a syntactic construct to aid authors in adding annotations to pages where the data to be annotated does not follow a convenient tree structure. For example, it allows authors to mark up data in a table so that each column defines a separate item, while keeping the properties in the cells.
</blockquote>
</div>

=== hReview item backward compatibility ===
It maybe necessary (pending research/evidence) to add backward compatible parsing for the class name "item" inside the backward compatible parsing for the root class name "hreview". If so, here are some notes on how to add that to the [[microformats2]] spec on v2 vocabularies.

==== h-item ====
...

For backward compatibility, microformats 2 parsers {{should}}, when parsing an "hreview" for backwards compatibility, detect the following root class name and property names. A microformats 2 parser may use existing microformats [[parsers]] to extract these properties. If an "h-item" is found, don't look for an "item" on the same element.

compat root class name: <code id="item">item</code><br/>
properties: (parsed as '''p-''' plain text unless otherwise specified)
* <code>fn</code> - parse as '''<code>p-name</code>'''
* <code>photo</code> - parse as '''<code>u-photo</code>'''
* <code>url</code> - parse as '''<code>u-url</code>'''

Note: we should analyze [[hreview-examples-in-wild]] to see if there are any that actually depend on parsing for "item", or if simply looking for "fn", "photo", and "url" directly inside a root class name of "hreview" is sufficient. If so, we should '''DROP''' this backward-compat parsing for the class name "item" as it may otherwise produce too many false positives ("item" is a fairly common term).

==== h-review ====
...
* <code>item</code> - including compat root vcard|vevent in the absence of h-card|h-event
...

Note: we should analyze [[hreview-examples-in-wild]] to see if there are any that actually depend on parsing for "item", or if simply looking for "fn", "photo", and "url" directly inside a root class name of "hreview" is sufficient. If so, we should '''DROP''' the backward-compat parsing for the class name "item" as it may otherwise produce too many false positives ("item" is a fairly common term).

=== register a mime type? ===
See [[microformats2-mime-type]].

== accepted ideas ==
=== more on allow root class name only ===
This has been stable for a while, see:
* [[microformats-2-implied-properties]]

== rejected ideas ==
=== n prefix for multiple numbers ===
Idea:

* '''"n-*" for (one or more) numbers''', e.g. "n-rating", "n-geo", leaving the semantics of more than one number up to specific format. e.g. for an "n-rating" inside an "h-review", the first number would presumably be the rating value, when only two numbers the second would be the "best" value (e.g. rated <code><span class="n-rating">3 out of 4</span></code>), when three numbers the second would be the "worst" and the third would be the "best" (e.g. <code><span class="n-rating">7.5 out of 1 to 10</span></code>). similarly "n-geo" would specify the first number to be the latitude and the second to be the longitude.

Rejected because while this *might* work for some properties in *English* it will NOT localize/internationalize well (orders of numbers in phrases change in different languages), and it will also limit the human expressivity of the plain text. Thanks to Ben Ward for this feedback at the 2011-06-02 microformats dinner. [[User:Tantek|Tantek]] 14:25, 9 June 2011 (UTC)

=== incorporate rel ===
Update: requiring rel with class tends to confuse web authors (lots of anecdotal experience here), thus [[microformats2]] itself does not require any use of rel by publishers, and keeps it only as part of backcompat handling of a small handful of classic microformats (e.g. [[rel-tag]] in [[hAtom]], [[hCard]]).

The rest of this proposal (of formally adding rel-* handling inside of microformats root class names) was rejected long ago.

==== profile h-card rel-me ====
Many sites have profile pages (personal home pages, and social networks), marked up with hCard, and permitting one or more rel-me values to other profiles, e.g. if this content were on <nowiki>http://tantek.com/</nowiki> :

Tantek Çelik ([https://twitter.com/t @t], [http://github.com/tantek github.com/tantek])

with source:

<source lang=html4strict>
<span class="h-card">
<span class="p-name">Tantek Çelik</span>
(<a class="u-url" rel="me"
href="https://twitter.com/t"
>@t</a>,
<a class="u-url" rel="me"
href="http://github.com/tantek"
>github.com/tantek</a>)
</span>
</source>

Parsed JSON per microformats2 properties:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://twitter.com/t",
"http://github.com/tantek"]
}
}]
}
</source>

We could incorporate rel property parsing either as just another property (like a 'u-' property) scoped to the microformat:
<source lang=javascript>
{
"items": [{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://twitter.com/t",
"http://github.com/tantek"],
"rel-me": ["https://twitter.com/t",
"http://github.com/tantek"]
}
}]
}

</source>

Or as always within global scope (closer to HTML5's currently defined scoping for 'rel' attributed links in a document):
<source lang=javascript>
{
"items": [{
"url": "http://tantek.com/",
"rel-stylesheet": ["...", "..."],
"rel-me": ["https://twitter.com/t",
"http://github.com/tantek"]
},
{
"type": ["h-card"],
"properties": {
"name": ["Tantek Çelik"],
"url": ["https://twitter.com/t",
"http://github.com/tantek"],
}
}]
}
</source>

Note: "url" in that root level object is the URL of the document itself, which is necessary for:
* 'rel' semantics: which URL from to which other URL the rels apply to.
* vCard .vcf export "SOURCE:" property (URL that the vCards were derived from).

== see also ==
* [[microformats2]]
* [[microformats2-parsing]]
* [[microformats2-brainstorming]]
* [[microformats2-experimental-properties]]
* [[microformats2-prefixes]]
* [[microformats2-implied-properties]]
* [[microformats2-faq]]
* [[html-stripping-examples]]
* [[microformats2-origins]]

microdata

2020-12-14T21:37:01Z

Btrem: Corrects status of microdata at W3C (editors for microdata were found, so the standard survived. Rumours of its death were greatly exagerated.)

{{DISPLAYTITLE:microdata}}

<dfn style="font-style:italic;font-weight:bold">microdata</dfn> is part of [[WHATWG]]'s [[HTML]] living specification that provides another way to embed [[microformats]] and [[poshformats]] vocabularies, and has been superseded by [[microformats2]].

microdata was due to be dropped by the W3C (and was therefore no longer going to be part of W3C [[HTML5]]) due to a lack of interest by anyone to edit the spec and keep it up to date.[http://lists.w3.org/Archives/Public/public-html-admin/2013Oct/0018.html] However, the W3C has a current [https://www.w3.org/TR/microdata/ microdata working draft].

== summary ==
microdata consists of a set of attribute extensions to [[HTML]]:

* <code>itemprop</code> attribute is a more specific version of <code>class</code>, for field names
* <del><code>subject</code> attribute allows semantically linking within the page. Conceptually similar to the [[include-pattern]].</del>
* <code>itemref</code> attribute allows including properties elsewhere on the page that are not descendants of <code>itemscope</code>. Takes space-separated ids (for example <code>itemref="address phone"</code> would include the elements with <code>id="address"</code> and <code>id="phone"</code>). Conceptually similar to the [[include-pattern]].
* <code>content</code> attribute on the <code>meta</code> element can be used to include invisible data that is not part of the content. As current browsers move <code>meta</code> inside <code><head></code>, make sure to include via <code>itemref</code>. Conceptually similar to the 'value-title' feature of the [[value-class-pattern]].
* <code>itemscope</code> attribute identifies blocks to be marked as structured data. Conceptually similar to the [[mfo]] brainstorming.
* <code>itemtype</code> attribute to specify the type for an item (for example: <code><nowiki>itemtype="http://microformats.org/profile/hcard"</nowiki></code>)

For common semantics on the web (e.g. [[hcard|people+organizations]], [[hcalendar|events]], [[hreview|reviews]], [[hatom|syndicated content]]), [[microformats]] are still simpler and easier than [[microdata]], and are already well implemented across numerous tools and services.

For uncommon, rare, experimental, or one-off semantics:
* [[microdata]] offers a simpler and easier to understand solution than alternatives that use [[namespaces]] like XML/RDF/RDFa. Developers may consider [[microdata]] as another way of expressing semantics that they may otherwise use [[poshformats]] for.
* '''[[microformats2#VENDOR_EXTENSIONS|microformats2 offers extension methods]]''' for adding both vendor extensions (e.g. h-vnd-* p-vnd-* etc.) and experimental extensions (e.g. h-x-* p-x-* etc.) and as such should be considered for another simpler way of expressing extended, one-off, custom, or site-specific semantics.
Either way, such uncommon, rare, experimental, or one-off semantics in the wild should be documented so they may inform possible future microformats vocabularies.

== history ==
microdata didn't happen overnight. Much of the design and simplicity of microdata is based on years of work on microformats [[principles]] deliberately designed to help guide and create simpler, more usable and accessible solutions. It happened so quickly because Ian Hickson designed microdata based upon years of work by both the microformats community, and the concept of using reverse-domain-names as unique qualifiers (popularized perhaps by Java programming language naming conventions).

most recently, lessons learned from the microdata parsing/data model were incorporated into [[microformats2]] which now serves as a functional replacement thanks to the [[microformats2-parsing]] specification.

== parsers and tools ==
[http://schema.rdfs.org/tools.html schema.rdfs.org has a list of tools].

* Python: [https://github.com/edsu/rdflib-microdata rdflib-microdata]
* Ruby: [https://github.com/gkellogg/rdf-microdata RDF::Microdata]
* Ruby: [http://lawrencewoodman.github.com/mida/ Mida]
* PHP: [https://github.com/linclark/MicrodataPHP MicrodataPHP]
* JavaScript (jQuery): [https://gitorious.org/microdatajs/ MicrodataJS]
* Java: [https://any23.apache.org/ Any23]

== microdata vocabularies ==
Separate from the [[microdata]] specification, there are a number of microdata vocabularies, based on microformats and previous formats like vCard and iCalendar.

=== microdata vCard vocabulary ===
Formerly documented as a separate specification at <nowiki>http://dev.w3.org/html5/mdvcard/</nowiki>, the microdata vCard vocabulary is currently available as [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard part of WHATWG additions to HTML].

* Recommendation: use [[h-card]] directly instead.

If you're specifically looking to produce Google Rich Snippets, use [[hCard]] in addition to [[h-card]].

Note:
* Avoid the "microdata vCard vocabulary" as in many ways it is an out-of-date fork/snapshot of hCard, even though portions of it appear to based directly on the vCard RFC. as well.
* Avoid Google’s Rich Snippets vocabularies ([http://www.data-vocabulary.org/Person/ Person] and [http://www.data-vocabulary.org/Organization/ Organization]), which are also forks of hCard/vCard, and are only implemented by Google currently.

=== microdata vEvent vocabulary ===
Formerly documented as a separate specification at <nowiki>http://dev.w3.org/html5/mdvevent/</nowiki>, the microdata vEvent vocabulary is currently available as [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vevent part of WHATWG additions to HTML].

* Recommendation: use [[h-event]] directly instead.

If you're specifically looking to produce Google Rich Snippets, use [[hCalendar]] in addition to [[h-event]].

Note:
* Avoid the "microdata vEvent vocabulary" as in many ways it is an out-of-date fork/snapshot of hCalendar's vevent root class name and applicable properties, even though portions of it appear to based directly on the iCalendar RFC.
* Avoid Google’s Rich Snippets vocabulary ([http://www.data-vocabulary.org/Event/ Event]), which is also a fork of hCalendar/iCalendar, and are only implemented by Google currently.

=== microdata Licensing Works vocabulary ===
Formerly documented as a separate specification at <nowiki>http://dev.w3.org/html5/mdwork/</nowiki>, the microdata Licensing Works vocabulary is currently available as [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#licensing-works part of WHATWG additions to HTML5].

The [[licensing]] microformat work provides a potential microformat alternative to the microdata Licensing Works vocabulary.

Please see: [[licensing-brainstorming]] and provide feedback.

== microformats in microdata ==
For those that are ok with going with an [[HTML5]] only solution, it may be interesting to consider and document a consistent way to use microformats and microformats vocabulary in microdata.

A possible simple implementation could look like this:

<source lang="html4strict">
<!DOCTYPE html>
<html lang="en">
<head>
<title>Corey Mwamba</title>
</head>
<body>
<section itemtype="http://microformats.org/profile/h-card" itemscope>
<h1 itemprop="name">Corey Mwamba</h1>
<p itemprop="street-address">56 Nowhere Road</p>
<p itemprop="locality">Nowhere</p>
<p itemprop="postal-code">NO1 6QT</p>
</div>
<a href="http://www.coreymwamba.co.uk/" itemprop="url">My web site</a>
</section>
</body>
</html>
</source>

And here's an simple [[h-event]] example:

<source lang="html4strict">
<!DOCTYPE html>
<html lang="en">
<head>
<title>Web 2.0 Conference</title>
</head>
<body>
<div itemtype="http://microformats.org/profile/h-event" itemscope>
<a itemprop="url" href="http://conferences.oreillynet.com/pub/w/40/program.html">
http://conferences.oreillynet.com/pub/w/40/program.html
</a>
<span itemprop="summary">Web 2.0 Conference</span>:
<time itemprop="start" datetime="2005-10-05">October 5</time>-
<time itemprop="end" datetime="2005-10-07">7</time>,
at the <span itemprop="location">Argent Hotel, San Francisco, CA</span>
</div>
</body>
</html>
</source>

The advantage is that no major re-wiring in thinking is required to adjust real-world usage - but would parsers be able to deal with the change? And in fact, would this require a recasting of microformats themselves? --[[User:Epicurious|Epicurious]] 19:16, 16 August 2010 (UTC)

== alternatives ==
Since the introduction of [[XMDP]], web authors have been able to define their specific uses of rel attribute values and class names.

(needs expansion with examples)
...

== see also ==
* [[HTML5]]
* [[poshformats]]
* [[principles]]
* [[XMDP]]

menu-brainstorming

2020-12-14T19:00:08Z

Btrem: Proposes using p-nutrition for recipe items that have calories added to it, with caveat that it is not part of h-product.

{{stub}}

Per [[process]], for documenting ideas towards a restaurant [[menu]] microformat, based on experience and research into:
* [[menu-examples]]
* [[menu-formats]]
And of course using existing microformats as building blocks when appropriate.

== Brainstorming ==
There may be some similarities with [[h-resume]], which also has an [[h-card]] for the organization (e.g. restaurant) whom the resume belongs to.

The obvious path forward is to use [[h-product]] for menu items. [[h-product]] offers pretty much everything a menu item microformat needs: p-name for the item name, (e.g. mushroom soup), u-photo, e-description, and p-price. There are some additional things in menus, notably calories, that might require a new property. If a menu has a page for individual items, u-url is available. [[h-review]] might be useful for review sites like Yelp or Google (though that might be a disincentive for restaurants, which tend to harbor strong antipathy to review sites in general and Yelp in particular. I'm not sure if p-category can be reused, but some way to tag items -- as vegetarian, gluten-free, etc. -- would be useful. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:12, 4 December 2020 (UTC)

Yes, p-category makes sense as a general tagging model. Gathering examples of categories used is useful to see what may be worth including as examples. [[User:Kevin Marks|Kevin Marks]] ([[User talk:Kevin Marks|talk]]) 15:04, 4 December 2020 (UTC)

What's missing is a container for the menu items. Such a menu container microformat could include meta information such as availability (e.g., a dinner menu is available 5pm -10pm). [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 02:14, 4 December 2020 (UTC)

A menu container needs a way to distinguish sections that is flexible to account for language differences and restaurant conventions. This could present challenges to third party consumers. However, I think a menu microformat should not get bogged down in such details. It's conceivable that a restaurant and third party could agree on a set of additional classnames for interoperability. So if menu aggregator Foo Delivery Service could look for a class name specific to its service in addition to any microformats, e.g., <code>section class="starter foo-deliver"</code>. The <code>starter</code> classname would be a microformat spec, used by menus everywhere, while <code>foo-deliver</code> would be specific to Foo Service, a way for a restaurant to specify that it offers items in this section for delivery by Foo. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 15:20, 4 December 2020 (UTC)

A simple solution might be to have a container for a menu section /instead of/ a container for a menu. That would allow a website to have a menu spread over several pages, each one with a single container element. If a website wants to put it on one page, they could place the container elements on one page, one after the other. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 16:31, 4 December 2020 (UTC)

Ideas for property names:
* p-name for the name of menu, e.g. dinner, breakfast, etc.; or maybe desserts, wine list, appetizers, etc.
* p-seller - the retailer, i.e., restaurant, cafe, pub, etc, that is selling the menu items. This can be an embedded h-card. The name of this property should be generic enough to include a wide rage of food retailers, perhaps with the ability to include other types of businesses. Alternative property names for p-seller:
** p-brand - this has the advantage of reuse from h-product, but that might be a disadvantage, too: menu items will likely be nested h-products, so using p-brand on parent and nested type might cause confusion. There's an additional problem: p-brand as restaurant name might be confusing for authors who might reasonably assume that a property called p-brand refers to the item brand, not the restaurant brand. In other words, a restaurant called "Bavarian Pub" that sells Franziskaner beer might assign "Franziskaner" instead of "Bavarian Pub" to a p-brand property. Thus, p-brand is a strong "pass" for me.
** p-restaurant - simple and straightforward, but might give wrong impression of its intended use. I imagine a street vendor might not think of her/himself as a restaurant.
** p-organization - very adaptable, but not very intuitive.
** p-retailer - again, adaptable, but not as obvious as seller, and perhaps again might give wrong impression to street vendors or food kiosks.
* p-product -- the thing being sold, a beverage or dish, e.g., main dish, appetizer, dessert, beer, wine, etc. This can be an embedded h-product. The property name matches the embedded name, following the [[h-card]] convention which has a p-adr property that can be an embedded [[h-adr]]; and p-geo with optionally embedded h-geo. Also, p-product is both intuitive and adaptable. Obviously, a menu normally contains many items, so this would be a many-to-one relationship.

I realize that h-menu is not ready for a draft, hence why I'm putting these ideas in menu-brainstorming. It's just me bouncing ideas off the wall. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:45, 8 December 2020 (UTC)

One of the problems with coming up with a structure for h-menu is how to deal with menu sections. It seems like one simple solution is to allow [[h-menu]] to be nested. The outer container might have a p-name "Dinner". Then nested sections could be themselves h-menu instances, each with their own p-name set to Appetizers, Salads, etc. That would allow for simple, flat menus with a list of h-product instances, or complex menus with sections, sub-sections, etc., as needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 22:06, 10 December 2020 (UTC)

For prix fixe menus, there's no way to mark up choices with microformats. It probably makes sense to just markup the entire menu as one h-product, with all choices for each course in one large e-description. That is an honest representation of the menu and probably is good enough. Something more specific would have to be done in h-product, and shouldn't be implemented unless it's really needed. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 00:38, 11 December 2020 (UTC)

I just came across the p-nutrition property from [[h-recipe]], which could be reused for menu items that include calories or other (often required) nutritional information. There is, however, a problem: as proposed so far, h-menu would be a collection of p-products that could embed [[h-product]]. But p-nutrition is not part of [[h-product]]. Other h-menu properties would pertain to the menu as a whole, not to individual menu items.

... feel free to add more unstructured thoughts there.

== See Also ==
* [[menu]]

include-pattern-brainstorming

2020-12-14T18:41:48Z

Btrem: Adds proposal for itemref attribute.

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
<p>We have three branches in <span class="locality" id="ldn">London</span>,
including our head office in <span class="locality" id="ken">Kensington</span>:</p>
<ul>
<li class="adr #ldn">
<span class="street-address">123 Oxford Street</span>
</li>
<li class="adr #ken #ldn">
<span class="street-address">5 Kensington High Street</span>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a <span> element) where the included content should go:

<pre>
<p>Our head office is in <span id="ldn" class="locality">London</span> at:
<p class="adr">
<span class="street-address">5 Kensington High Street</span><br>
<span class="#ldn"></span>
<span class="postal-code">SW7 1AA</span>
</p>
</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre><span class="vcard">
<span class="data">
<span class="fn">Foo</span>
</span>
<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</span></pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre><span class="vcard">
<span class="include data"></span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

The result "could" turn out much like this:

example,
<pre><span class="vcard">
<span class="fn">Foo</span>
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span></pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr"><span class="street-address">665 3rd Street</span>, and</li>
<li id="adr2" class="adr"><span class="street-address">123 Folsom</span></li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has <span id="#adrlist1>office locations in <span class="locality">San Francisco</span></span>:
<a id="adr1" href="#adrlist1" rel="group" class="adr"><span class="street-address">665 3rd Street</span><span>,
and <a id="adr2" href="#adrlist1" rel="group" class="adr"><span class="street-address">123 Folsom</span></span>
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

=== Use html5 custom element ===
An include pattern could use a [https://html.spec.whatwg.org/dev/custom-elements.html custom html5 element] without any semantics, perhaps <code><mf-include></code>, with a custom attribute <code>includeid</code>. This custom attribute would work similar to how the standard <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute works. Authors could place a space-separated list of tokens in <code>includeid</code>. A microformats parser would then search the document for an element whose <code>id</code> matches one of those tokens, and include that matched element in the microformats element's sub-tree as if it appeared in that part of the DOM. Here's the first example on this page, marked up with the custom element instead of the class-based solution.

<pre>
<p>We have three branches in <span id="ldn">London</span>,
including our head office in <span id="ken">Kensington</span>:</p>
<ul>
<li class="adr">
<span class="street-address">123 Oxford Street</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
<li class="adr">
<span class="street-address">5 Kensington High Street</span>
<mf-include class="locality" includeid="ken ldn"></mf-include>
</li>
<li class="adr #ldn">
<span class="street-address">1 Pall Mall</span>
<mf-include class="locality" includeid="ldn"></mf-include>
</li>
</ul>
</pre>

There's a [https://btrem.github.io/microformats/include-pattern/ full write up of this idea] with links to two pages showing how this include pattern might work with the h-recipe format. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:24, 14 December 2020 (UTC)

=== Use html5 itemref attribute ===
Of course, since the [[include-pattern-brainstorming#Use_html5_custom_element|custom element idea]] is essentially based on html5's <code>[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemref itemref]</code> attribute, we could just use that attribute and call it good. [[User:Btrem|Btrem]] ([[User talk:Btrem|talk]]) 18:41, 14 December 2020 (UTC)

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:Guillaume Lebleu|Guillaume Lebleu]]

== Related Pages ==
{{include-pattern-related-pages}}