views:

529

answers:

5

Is it semantically correct to nest definition lists, or should they simply be a 'flat list of name/value pairs'.

The specs don't seem to forbid it.

Further to this question.

+2  A: 

At the spec says:

<!ELEMENT DL - - (DT|DD)+              -- definition list -->

A <dl> can only contain <dt> or <dd> as its immediate children

But each of these can contain more <dl>s. So yes, you can nest definition lists, but would you ever really want to?

Gareth
See the linked question. That seems like a good candidate for nested definition lists.
meleyal
A: 

Sure. There's nothing wrong with nested DLs. You can semantically have "subdefinitions."

Rob Kennedy
A: 

If it works in all the browsers, then do it.

I know this might be controversial, and a lot of people will probably tell you it isn't the way it's supposed to be used. The unwritten rules of webdesign, like using lists for almost anything, are just what people have decided to do. There is no reason why you should be using float (which purpose is to float an image inside a block of text) to layout every little detail on a website. But if you try to use tables you are an apparently an idiot from the pre-bubble era, and you have no idea how to design.

So, do what you want to do, and don't make things more complicated just to fix the problem.

Marius
+5  A: 

Well the spec seems to allow it, provided that only the <dd> contains nested lists. The spec states that a <dt> is an inline element, so it can't contain a nested list. A <dd> is a block element, so an inner list inside one of these is fine.

Yuliy
A: 

Interesting question.

It's true that DefLists are intended to represent Keys and Values, but the multiplicity on those isn't 1 it's 1+. If that complexity is allowed, and bearing in mind that dt's are inline, I see no semantic problem with representing defining something in terms of a tree of other things.

annakata