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?
Comments
I think this is one of the few real-world situations where definition lists are actually appropriate. TV listings are another that should be considered as definition lists (although, in theory, this is also an ordered list).
Wow. I’ve never heard of definition lists. Interesting article and thanks for bringing my attention to what is apparently a little-used html element. Just when I thought I had a handle on xhtml.
@Simanek: I’m glad you found the article useful!
@Si Jobling: I’m glad to hear you agree with my assessment. TV listings are another interesting real-world example to analyze. I’d like to take some time to think about the semantic value of television listings and perhaps write a piece on it in the near future if you wouldn’t mind.
About semantic web documents, a class
descriptionis too semantic, I think. The second ‘d’ stands for description. I think the classnamepriceis good, and with CSS the otherddcan also be styled.Jon, it’s nice to see someone shares my same opinion to markup a restaurant menu.. a while ago I’ve written something about it in How to style a Restaurant Menu, which is, btw, more focused on the presentation and the CSS. Nice read indeed, thanks for sharing!
@Arjan Eising: That’s a fantastic point, and you’re illustrating exactly why I enjoy talking about semantics as much as I do! Your solution is absolutely acceptable, and also allows you to trim your markup at the same time. Thanks very much for offering your thoughts.
@Alessandro Fulciniti: Wow, it’s amusing how similar our conclusions were! I hadn’t seen your article before but if I had I would have absolutely been sure to include it in my write-up.
This article couldn’t have been more timely for me. I’m actually working on a restaurant menu right now and trying to hash out (pun intended) the best way to mark it up. Definition lists intuitively make the most sense, for sure, but couldn’t you also argue that it’s tabular data? Isn’t the true purpose of a table to show the relationship between pieces of data (such as items, prices, and descriptions)? Imagine if the page were completely unstyled. If you used definition lists the menu would be hard to understand, but if you use tables it would be obvious. I think that’s a good clue that tables are appropriate. Also, I must confess, I’m worrying about the print stylesheet, which will be very simple if I use tables.
@Julie Hathaway: I’m really glad you found the article useful! Thinking about it, yes, I think that a menu could be considered tabular, should the proper headings be provided. Yes, tables are used to show data relationships, but on the same side of things, definition lists too show a relationship between pieces of data. In my personal opinion, I think a definition list better suits this particular example, but your idea is very well received. Regarding your worry about a print style, it should be no problem if you beautify your print CSS 🙂
Definition lists, though, only show one relationship: the term and the definition. Tables, on the other hand, show two relationships: the rows and the columns. When you’re looking at a menu it’s equally likely that you’d want to scan “across” to see the price, or “down” to see the next item. Imagine the menu with CSS turned off: a definition list would be a lot harder to read than a table. I think that in the case of tabular data the presentation IS the content. The physical layout of the table gives meaning to the data within, and that’s why XHTML provides th tags and so forth — to allow visually-impaired users to “see” the structure of the table and therefore understand it.
Regarding the print stylesheet — and please correct me if I’m wrong, I haven’t done too many of them — my understanding is that you’re supposed to avoid the kind of CSS positioning that would be required to make a definition list look like… a table.
Whew! I don’t know about you, but I think I’ve convinced myself anyway. And it’s a funny thing because I love definition lists and use them whenever I can. Go figure. 🙂
@Julie: You’re right in that definition lists show a specific relationship between a term and a description. The fact still remains, however, that each pairing is also contained in a single group as a list. Your arguments are quite strong in supporting that a menu could be considered tabular data, but definition lists seem to make a bit more sense to me, just as a personal preference however. Your comments have shown that it can be acceptable to use a
tableto mark up a menu, however.There are many time’s that I’ll use CSS to style a document so that some elements appear tabular even though they aren’t, as the organization is usually aesthetically pleasing.
I’m really glad you’ve included your thoughts here, and that helping you to come to your conclusion is completely great!