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-product
s
h-x-menu
as deep as needed to represent a food menu -
property details
The root and property names follow microformats2 design patterns:
- re-use existing class names where possible, and
- add an infix to mark new names and properties.
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:
- h-x-menu
- p-x-seller
- p-x-product
- e-x-section
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-menu
s,
using actual food menus from two restaurants that I
used to work for, shortened and slightly modified
for demonstration purposes.