On Thu, 4 Nov 2004, Thomas O'Connor wrote:

> I believe that it is vital for semantic purposes that definition lists
> remain how they are in HTML 4.0 through to XHTML 2.0 unless
> another name:value element set is included.

Here we go again. A definition list is a list of definitions. If you don't
know the definition of "definition", or more exactly don't care about it,
you can use <dl> for whatever you like - for formatting. And the W3C has
shown the way in the grossly self-contradictory section on <dl> in the
HTML 4 specifications.

There should be no <dl> element in XHTML 2.0, unless it is intentionally
designed to be compatible with traditional abuse of <dl> in HTML.

If you want something that really means a list of definitions, you should
at least name it differently, to avoid association with <dl> and to make
the markup less cryptic. On the other hand, you might also consider how
useful such a specialized construct is. Shouldn't we _first_ have markup
for a single definition, before considering a list of definitions (which
would appear to be a simple compound idea, composed of "list" and
"definition")? This would get rather complicated, since it's a real
problem and not just a made-up one, see
http://www.cs.tut.fi/~jkorpela/def.html 

> Definition lists allow for a huge number of name:value pairs to be
> semantically marked up in a way that cannot be reproduced through any
> other element set.

If you mean a set of name:value pairs, why do you call it a definition
list? And what's the _meaning_ (semantics)? It sounds like pure abstract
structure.

> Of course there are always tables, but they are more
> restrictive in their styling and positioning, plus are a bit of overkill.

If you mean that a special case of a table, namely a table with two
columns, needs specialized markup, then let's discuss _that_ (and not
definition lists). And if you have problems in formatting, then that's a
styling issue - and shouldn't it be solved in a manner that helps in
formatting, say, 1-column and 3-column tables, too?

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/