W3C home > Mailing lists > Public > www-html@w3.org > May 2003

XHTML 2.0 List Module negates the semantic usefulness of definition lists.

From: Ben Meadowcroft <cee.plus@virgin.net>
Date: Sat, 31 May 2003 13:20:59 +0100
Message-ID: <005e01c3276f$1870bac0$26e287d9@BensPC>
To: <www-html@w3.org>

This post highlights a few things:

1. Why the introductory text is wrong in relation to Definition Lists.
2. Example applications that could be seriously hampered by promoting
incorrect usage of definition lists.
3. The changes that should be made to accurately reflect the purposes of
definition lists.

Apologies if this has already been covered but I didn't find any mention of
this particular issue in my search of the archive.

1.

In "11. XHTML List Module"[1] the introductory text gives the impression
that definition lists are free to be used for "other applications" than
marking up definitions, I disagree with the open ended nature of the phrase,
definition lists should be used for marking up definitions only, the phrase
"other applications" can damage actual potential uses for "real" definition
markup.

I am suspicious of the phrase "other applications" and believe it promotes
the "this element is for presenting a bold phrase with indented text below
it" concept that I though XHTML 2 was trying to get away from. If this
becomes widespread in XHTML 2.0 then the usefulness of the definition list
will be reduced. One of the other applications proposed in the modules, in
11.1., is for "marking up dialogues", using definition lists. This
application is counter intuitive to the meaning of a definition list and
points to a lack in the specification of a more general/neutral list element
that relates two items together (like a DT DD pair).

Rather then wresting the semantics of the definition list why not introduce
a more general construct that authors can use to model these applications
(much as authors currently use the "content neutral" unordered lists for
navigation lists). Alternatively use a foreign namespace or module to
introduce specialised elements for marking up a dialogue.

2.

Example application. A glossary application could analyse a set of web
documents in order to extract from them definitions and terms for a specific
organisation to conduct a glossary document from a wider set of documents,
without the need to maintain a central repository document authors can
introduce new terms, with their own definitions, without having to manually
update a central glossary as well. I am implementing a similar scheme in a
prototype CMS I am building. If we "muddy the waters", as I suggest the
draft does, then the usefulness of such techniques is severely limited.

See also the google glossary [2]

3.

*Change*

"Definition lists, created using the dl element, generally consist of a
series of term/definition pairs (although definition lists may have other
applications). Thus, when advertising a product, one might use a definition
list:"

*To* (minimal change + some clarification on why the DL is used in the
example)

"Definition lists, created using the dl element, should contain a series of
terms and definitions. Thus, when advertising a product, one might use a
definition list to describe the terms used in the advert:"

*Or* (my preference)

"Definition lists, created using the dl element, should contain a series of
terms and definitions, as in a glossary:"
Replace the current example with an example of a glossary of common terms.

*Summary*

The proposed change removes the ambiguity caused by the "other applications"
phrase.
In addition it replaces the phrase "term/definition pairs" which states that
you have always have a term and definition as a pair while later examples
show that you can have multiple terms related to a multiple descriptions,
not the one to one relationship the term "pair" states.

regards
Ben Meadowcroft
http://www.benmeadowcroft.com

References:
[1] http://www.w3.org/TR/xhtml2/mod-list.html
[2] http://labs.google.com/glossary
Received on Saturday, 31 May 2003 08:21:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:55 GMT