Re: Issues with <dl> [continued from Re: Concerns about the "l" element name <l>]

I can see where you are coming form, and have always. However I think you are being very restrictive in your views.  You are taking
the element names too strictly/seriously, and not giving enough value to their descriptions provided in the recommendations.

> "Associating" is just a nice way of saying you need something to attach
> styles to and to have some default layout you want. Why else would you
> like to "associate" things?

> And there is no way
> to define it in a way that corresponds to its widespread use - because
> that use itself is purely presentational, used to achieve some simple
> layout, and if you try to capture that into some semantics, you find
> yourself in speaking about vague "associations".

I dispute all your references to <dl> being used for presentational purposes.  It simply isn't.  It used to associate for the
purpose of creating this association, as well as creating a barrier between the term and value - to give a value to some term, and a
term to some value, in the context of the information that it is provided with.

> It's quite comparable to saying that <blockquote>
> means 'block quotation' and then describe that it is used to indent text

I cannot see how you can make that comparison.  We aren't in anyway using <dl> for presentational purposes.  And if it is arguable
that we are, then it is also arguable that we are using XHTML (or any markup language) for presentational purposes.

> Even <dl><dt>E-mail</dt> <dd>jkorpela@cs.tut.fi</dd> ... </dt> does
> not _define_ the value of E-mail, still less the _meaning of the term
> "E-mail"_, which is what it should do if the markup were compatible with
> the definition of <dl> semantics.

It doesn't define _the_ value of E-mail, it defines _a_ value of E-mail in a given circumstance.

> That's what I have been saying. <dl> is a complete failure.
> Its usage, and even the descriptive part of the HTML specs,
> does not correspond to its defined meaning.

"defined meaning"?

> And it would be particularly strange to keep the tag names. If
> <dl> does not mean definition list (a list of definitions), why
> call it <dt>? It <dt> does not mean definition term (a term being
> defined), why call it <dt>? If <dd> is a value of a variable, or the
> words of an actor, or some comments on something, and not definition
> data, why call it <dd>?

<dl>, <dt>, and <dd> mean definition list, definition term, and definition data because they define associations.  Not necessarily
this strict view of what a definition list is that people are adopting.

> That is, only if you think words have meanings and once you have _defined_
> something you cannot proceed to babbling about something completely
> different "use" for it.

The XHTML 2.0 draft  states:  " Definition lists vary only slightly from other types of lists in that list items consist of two
parts: a term and a description. "[1].

It does not say what the term is, nor what the description is.  It in no way says that it must be a word and its meaning.  Surely
the only meaning perceivable from that statement is that there is some association between the term and the description.



Despite my continued argument that <dl> was not intended in the strict way, I feel the W3C should revise its definition of
definition lists - either removing the part about dialogue and stating that it is only for word definitions, or clarifying that it
can be used to create simply associations between terms and values.

I also believe that in some circumstances it would probably be better for semantics if certain definition lists currently
implemented were placed in tables, as it allows descriptive headings for the different name:values, which is useful for semantics,
and can be just hidden if the designer doesn't wish for them to be displayed due to it being inherently obvious what the columns
contain.

Until the time that the W3C clarifies the purpose and use of <dl> I can see no resolution to this matter.



[1] http://w3.org/TR/xhtml2/mod-list.html#sec_11.1.



Thomas O'Connor, me@ocoth.id.au, http://ocoth.id.au/

Received on Friday, 5 November 2004 05:04:03 UTC