A Semantic Breakdown of Restaurant Menus

Published 10 years 1 month ago on May 14, 2007 — 6 min read

Personally, one of my biggest interests in HTML is the semantic nature of the language when used correctly to mark up a document. I enjoy thinking about what markup is most appropriate for a given piece. HTML has been long abused by many Web developers who do not understand the concept of semantics, and how much weight a tag you use can carry when used for its true purpose. Improper semantic use of HTML tags is the root of many problems of the modern Web. The most widely spread problem that comes to mind is the use of tables to structure a site design. Web developers now (should) know that there are more appropriate ways to structure their design using CSS. Semantics goes far beyond not using a table for your layout, and by nature semantics can be debated. The call for discussion associated with semantics is another reason I enjoy Web development as much as I do. When speaking with intelligent developers, lots of great conversation can be had regarding specific examples of semantic markup.

When browsing around the Web lately, I’ve been excited to read that many other developers seem to feel the same way as me. A new discussion has been brewing among Web developers on the topic of POSH. This recent revival seemed to at least partially stem from an article written by Jeremy Keith entitled POSH Patterns. POSH (Plain Old Semantic HTML) has the potential of becoming a buzzword much like “Ajax” and “Web 2.0”, but to me, this buzzword stands out from the rest. Should POSH catch on in the same way, it would benefit not only each and every developer who researches it, but any website they work on as well. It is, by nature, difficult to abuse or misuse.

I’d like to start doing my part in spreading the word about POSH in starting a sporadic series of articles on the subject, much like the ‘Improving your Process‘ series. In the articles I’ll take a real world example that will hopefully be found useful by developers at some point in their career. I’m also hoping that the articles will spark some lively conversation in both agreement and opposition to anything I bring up. I don’t want the articles to be looked at as the final word in the least, I’d just like to offer my opinions and be completely open to any and all reactions.

The first article in this series, had I thought of it at the time, would have to be my questioning of calendar semantics, an article in which I ask which is more appropriate for marking up a calendar: a table or a list? There were some great comments in response to that article and I hope a similar situation results from those upcoming in the series.

Applying POSH to restaurant menus

The first official article in this series is going to take a close look at how you could mark up a menu for a client running a restaurant. When you think about a menu, most of the time the name of the dish is offered, as well as a description and of course, a price. When you break down what needs to be marked up, we’re given the ability to analyze how elements can be used in cooperation with semantic HTML.

There are a number of ways you could mark up a restaurant menu, the most simple that comes to mind is a group of headings and paragraphs which hold the dish name and description/price, respectively. That’s not the worst way to go about things, but there is something better that can be done. Definition lists seem like a perfect way to handle marking up a restaurant menu.

Definition lists are, in my opinion, underrated

Definition lists are something I find myself using all the time since discovering their usefulness. If you take a look at a project you’re currently working on, there’s a good possibility a list you’re using could be considered a definition list. Definition lists are not strictly limited to terms and their definitions. Definition lists are used to list items that consist of two parts: a term and a description. There are many times that a list of items consists of two parts that are directly related.

Beyond their semantic usefulness, definition lists are quite a blessing when it comes to styling them. The elements are structured in a way which allows you to achieve a very organized and tidy look without bloating your markup. If you aren’t currently making use of definition lists on a fairly consistent basis, I’d highly recommend it where applicable.

Applying a definition list to a menu

When marking up a restaurant menu, I would include the dish name as a dt element, and then the description and price as separate dd elements. To me this makes sense because both the description and price are directly related to the dish title. Keeping POSH in mind helps us to also provide meaningful class names for the elements by applying class="price" and class="description" to each dd not only to distinguish a difference between the two, but will also help out with styling the list.

<dl>
  <dt>A Sample Dish Du Jour</dt>
  <dd class="price">$8.99</dd>
  <dd class="description"><p>Lorem ipsum dolor sit amet,
    consectetuer adipiscing elit. Morbi suscipit urna placerat
    turpis. Vivamus id sapien eu augue pellentesque tincidunt.
    Proin vel ante aliquet pede congue porta.</p></dd>
</dl>

There are also some items on a menu that may not have either a price listed (if the prices are noted elsewhere) or a description (for something like the soup du jour). Those items can simply be left out, and the associated class will help to keep your styles in tact.

Other elements required by a restaurant menu

Not everything included in a restaurant menu can be marked up using a single definition list. In actuality, multiple definition lists, headings, and other lists will be needed to effectively mark up an entire menu. The different menu sections can be included in their own div including their own heading, as well as class to help distinguish a lunch menu from a dinner menu for example.

Going further, every list in a menu won’t always be a definition list. There is often a need for an unordered list for one reason or another in a restaurant menu. What counts is that each section is taken into consideration and ends up using what makes the most semantic sense. There will also more than likely be an appropriate place to use an address element, providing any location details or phone numbers for the restaurant.

I’ve attempted to be mildly general in taking restaurant menus into consideration. It’s very likely that there will be more to take into consideration when actually implementing a menu, but hopefully this article has set the wheels in motion as far as a thought track is considered. Have you had to implement a menu online before? What markup did you use? Do you agree that a definition list is the way to go from here on out? Or do you think I’m completely wrong and feel that there’s a better way? What other opinions do you have on the matter?

Copyright © 2006—2017 Jonathan Christopher