<ul> vs <dl> for menu

[Kurashu]

Is it better to use an unordered list (<ul>) as opposed to a definition list (<dl>).

The issuse of links in a menu being a list aside, it is techincally defining what the navigation includes (i.e. the different sections of the site). Also, would it not aslo be more semantically to use on <dl> and multiple <dt> and <dd> tags for sub-sections of the site?

I dunno, that's just my two cents.

[codegoboom]

I have nothing to add, but a link... Definition lists - misused or misunderstood? (http://www.maxdesign.com.au/presentation/definition/)

[brothercake]

Neither is wrong or right in absolute terms - it depends on the data.

[ronaldb66]

... although I can't really see a top menu item and it's sub menu items as a description term - description definition pair; besides that, it would limit the number of levels to two (not that that's a bad thing, though...).

[brothercake]

No I can't see that either - I think a menu is a nested list.

But what kind of list ... some navigation data might be structured into name/description pairs, and you might feel that info is best represented as a <dl>, rather than a <ul> with title attributes on the links.

[Jalenack]

How about a sitemap, that fits in with definition lists, right?

Say I've got all sorts of categories that I want to put my links into. I could use a dt for the category title and multiple dd's for items in that category?

Definition lists have always kind of perplexed me as to their usage

[brothercake]

Well you could do that, but I personally think that's stretching the semantics a bit .. for a sitemap I use a regular nested lists, with headings around the top-level links to provide a degree of random-access for serial browsers. Like this:

<h2>Sitemap</h2>

<ul id="sitemap">
<li><h3><a href="/" title="Home page">Home</a></h3>
<ul>
<li><a href="/access/">Accessibility</a></li>
<li>Sitemap (this page)</li>
<li><a href="/search/">Search</a></li>
</ul>
</li>

and so on..

[Graft-Creative]

I've been thinking about this a lot lately (yes, I need to get out more)
It seems like the argument for using lists for navigation has been fought and won already, unfortunately I've yet to find the war diaries, so I dunno how this conclusion was reached.

The thing is, looking at unordered, or ordered lists in other mediums - the list is always preceeded by a defining statement or term.

Like say I have:

bread
do a jigsaw
milk
clean PC

Is that a list, or just a bunch of words?

Does it only become a list when I add a defining statement, like:

things I need to do/buy today:

bread
do a jigsaw
milk
clean PC

In which case, is it not a DL?

Yes I'm bored, and yes I need to get out more, but I've been wondering about the usefulness of the unordered list for a while now, and part of me sees it as a relic - originally included in html as a way of visually representing the bulleted lists we all know from WP programs?

Kind Regards,

Gary

[brothercake]

Does it only become a list when I add a defining statement
No not necessarily - it's still a list even if its defining statement is implied from the content of the list. The point of the defining statement is so it's easier to understand, so you know what the list is before you start reading it. That's not so much a point of semantics as an editorial decision. But given that you decide to do that, the semantics offer a number of structures for presenting it.

... In which case, is it not a DL?
Yeah it could be. These two structures are essentially equivalent:


<h*>Things to do</h*>
<ul>
<li>first thing</li>
<li>second thing</li>
<li>third thing</li>
</ul>

<dl>
<dt>things to do</dt>
<dd>first thing</dd>
<dd>second thing</dd>
<dd>third thing</dd>
</dl>

Now I would favour the former, because it's part of a headings heirarchy, which is good for serial browsers (and also SE robots);

But it's not self-contained, so usually requires another containing div around each block. A definition list is more compact and convenient to style - and especially useful if your target is a dynamic page where its location in the headings heirarchy is not known.

But other than that, I tend to preserve them for things where the definition list is properties or subsidiary information to its context; things where the inate flow of the data falls into key/value pairs - such as what I did for forum threadview markup http://www.codingforums.com/showthread.php?t=40373 or what I do in my menu documentation http://www.udm4.com/manual/customising/core/#customising-core-reset

It really comes down to judgement calls - what do you think is right in a particular circumstance (judged as objectively as you can, trying to ignore practical or implementation issues when making that decision).

I just go with the flow on that kind of thing ... what feels right instinctively, and still seems like a good after thinking about it; if instinct and rationale agree, it's usually a winner :)

[mindlessLemming]

Bah, forget all this bloated markup....

<nl>
<label>Contents </label>
<li href="#introduction">Introduction</li>
<li>
<nl>
<label>Terms</label>
<li href="#may">May</li>
<li href="#must">Must</li>
<li href="#should">Should</li>
</nl>
</li>
<li href="#conformance">Conformance</li>
<li href="#references">References</li>
</nl>


...oh wait, that won't work for another decade :(

[chilipie]

I have absolutely no idea what an <nl> is :D .

[jkd]

I have absolutely no idea what an <nl> is :D .

XHTML 2.0.

[gsnedders]

Here's a description of it: http://www.w3.org/TR/xhtml2/mod-list.html#sec_11.2.

Hell... I can't wait.

[brothercake]

nl = navigation list, I believe. It formalises the notion of a navbar as a list, by giving it its own kind of list.

[jbot]

you could always revert to this:

<menu>
<li><a href="http://www.google.com/">Google</a></li>
<li><a href="http://www.altavista.com/">Alta Vista</a></li>
</menu>

oh wait, that's now deprecated. funny that they've now proposed navigation lists when they used to have the menu tag, eh? :rolleyes:

[codegoboom]

funny that they've now proposed navigation lists when they used to have the menu tag, eh? :rolleyes:
Good point, I wondered about that too... :)
oh yeah... that reminded me of something:


Discussion of Bowers' Law (A program can not safely rise above its data structures.)

A programmer can try to extend a program's data structure's capabilities with code for some specific purpose, but the code for various purposes will inevitably get out of sync, the kludges necessary to compute values that should be stored as data start conflicting (often because of massively different hidden assumptions), copy & paste programming proliferates, and the whole becomes difficult to extend. It rapidly collapses into something too complicated for a mere mortal to understand. This kind of complexity causes geometrically more effort to be required for every new feature... and in the worst cases, every new bug fix!

If a program must be put to new purpose, if the program's behavior must get significantly more sophisticated, the sophistication must almost always come from more sophistication in the data structures, not the code.

Example: Witness the wide variety of web pages that try to implement something as simple as hierarchical menus with Javascript (http://www.webreference.com/dhtml/hiermenus/). It is a true challenge, so much so that the linked web page is attempting to sell a solution for that problem, something that seems so simple it should be of negligible price. The fundamental problem is that HTML has no support for "menus", compounded by the wild differences in browser capabilities. In this case, the only choice is to try to glue together support for menus with code, but it's still difficult, must be frequently updated as browsers change, is effectively impossible to extend, and for all this effort is still painfully quirky. HTML, considered as a data serialization protocol, is simply not rich enough to represent menus, and the addition of Javascript to the mix only allows something "close" to work.

The optimal solution is to add a true menu to the browser. In the web arena this is generally not feasible and necessitates such hacks as in the linked menus, but just because they were forced to violate Bowers' law to get to the their goal does not mean they are immune to the effects. If you do use a non-cross-platform browser extension, such as ActiveX controls, then you can get very good ways to express "menus" cleanly.