BTrem

microformats food menu idea

This is a rough sketch for a food menu microformat that I first suggested on the microformats irc channel in late . Following that suggestion, I added several ideas to a newly created wiki page devoted to menu brainstorming. I then decided to try out some of those ideas by marking up web pages with food menus, which meant I had to come with names for the root menu and its properties. The proposal in this article is a result of that effort.

root name

The class h-x-menu is the proposed root class name that indicates the presense of an h-x-menu. It can also appear as a nested property to represent menu sections. See the menu section property.

properties

p-name
name of the menu, e.g., breakfast, dinner, etc.; or menu type, e.g., à la carte or prix fixe menu; or, in a menu section that is a nested h-x-menu, name of the menu section, e.g., appetizers, main dishes, desserts, beverages; or perhaps brunch, dinner, etc.
p-x-seller
h-card
restaurant, vendor, or other organization or person selling products listed on the menu; can be a nested h-card; see h-card
p-x-product
h-product
menu item, e.g., an individual appetizer, dessert, beverage, etc.; can be an embedded h-product, which would allow product details like price, photo, or description; see h-product
e-x-section
h-x-menu
menu section; can (should? must?) be a nested h-x-menu with its own:
  • p-name, e.g. breakfast, lunch, dinner (for a menu divided by meal); or appetizers, main dishes, desserts (for a menu divided by course); or pasta, meat, fish (for a menu divided by primary ingredient); etc.
  • list of one or more p-x-products
authors can nest h-x-menu as deep as needed to represent a food menu

property details

The root and property names follow microformats2 design patterns:

re-used names and properties

p-name is re-used from a number of microformats, including h-event and h-recipe.

h-card and h-product, which appear as nested types, are established microformats.

new names and properties

There are several new names, all designated as experimental by the inclusion of an -x- infix:

requirements

Each h-x-menu instance should have only one p-name and one p-x-seller. But note that h-x-menu can include nested h-x-menu instances to represent menu sections, each of which can have its own p-name. In principle, a nested h-x-menu could also include an additional p-x-seller, though that could be discouraged. Or perhaps that could prove useful if one part of a food menu is sold by a person or company independent of the seller specified in the root h-x-menu instance.

Each h-x-menu instance should (must?) contain at least one p-x-product, but can include more than one.

demo menus

I have created several demo h-x-menus, using actual food menus from two restaurants that I used to work for, shortened and slightly modified for demonstration purposes.