Re: XHTML2 dt/dd Nesting

> [Original Message]
> From: Stefan Ram <ram@ZEDAT.FU-Berlin.DE>
> To: W3C HTML List <www-html@w3.org>
> Date: 11/15/2003 3:24:04 PM
> Subject: Re: XHTML2 dt/dd Nesting
>
>
> Ernest Cline wrote:
> ><di>
> >I'll admit to a certain bias in favor of this form as I proposed it.
>
>   I understand that this is meant to appear within
>   a dl element. This still implies that a definition
>   makes sense only as part of a list of definitions.
>   I see no reason for this restriction.

A definition need not only appear in a list, but historically
in (X)HTML the only way to indicate the pairing of a term
with its definition was via a <dl> even if that <dl> was
only one <dt> and one <dd>.

Inline definitions were handled via the <dfn> element,
altho that element only provided a way to mark the term
being defined and not the scope of the definition.

>   Element types of XHTML(n) should be based on two design
>   principles:
>
>   - The space of all possible text types occurring in XHTML
>     use cases (like definitions, headings, or acronyms) is 
>     divided into several subspaces.
>
>     This division might be very coarse, but it must cover
>     the whole space.
>
>     Each subspace corresponds to an XHTML element type.
>
>     The user of XHTML then may subdivide any of theses 
>     subdivisions further by using the attribute "class".
>
>   - Element types can be combined to express text types,
>     if appropriate, and therefore should be as orthogonal
>     as possible.
>
>     For example, if "cite" is a citation and "acronym" an
>     acronym, then "<cite><acronym>...</acronym></cite>"
>     cites an acronym.
>
>   So, two things are wrong with "di" - or whatever it
>   is called:
>
>   - First, this only covers a special subdivision of text
>     types, leaving other divisions completely uncovered, so
>     that the user can not reach them by specializing
>     the element type with a class-attribute.
>
>     The more general text type here is a binary relation
>     between two texts, like
>
>       * a /term/ and its /definition/,
>
>       * a /question/ and its /answer/ (as in an FAQ-list),
>
>       * a /speaker/ and its /utterance/,
>
>       * a /word/ and its /translation/.

First off, because of that fact that <dl> is currently used
for other types of binary pairs than definitions, I am in favor
of not referring to it as "definition list" but with some other
terminology. The best I could come up with that would
not require changing the name of the element was "d-list"
but  focussing upon the binary relationship has made me
think that perhaps something like "duple list" since a <dl>
consists of duples, would be best. [1]

>     Thus, XHTML should offer a general element type for such
>     a text pair, so that the user can specialize it to the
>     grade of detail needed by a class attribute. A definition
>     element then would be such a special case. XHTML also might
>     include some special case element types (like definition
>     element types), but there should still be a general
>     text-pair element type, so that the user can use this
>     if no more-special element type applies.
>
>   - Second, "di" is based on the assumption, that a definition
>     only makes sense as an /entry/ in a definition list. In math
>     books and other text types this usually is not the case.

From what I have seen of textbooks, <dl>'s that would contain
but a single <di> are fairly common, and for definitions that are
inline to a paragraph, the <dfn> element suffices. Because
such inline definitions can overlap, a container element for
the definition usually doesn't work for the general case, altho
giving the definition via the title attribute (or perhaps an
attribute specific to <def> would seem to be the
best available solution.

>     XHTML should offer a general list container, so that the
>     user can create a definition list in the most natural way:
>     as a list of definitions, i.e., as an element of type "list"
>     containing elements of type "definition" as direct sub elements.
>
>     This general list container might even be the "ol" and "ul"
>     element type. As of now, I can not tell, whether a
>     definition list is ordered (a definition might refer to 
>     preceding definitions) or unordered (each definition stands
>     on its own). If one could use a general definition element
>     within "ol" or "ul", even that distinction would become
>     possible by combining "ol"/"ul" and such a definition element
>     as a direct child.
>
> http://purl.net/stefan_ram/

I'll leave alone for now whether the distinction between
an ordered and an unordered list is semantically sufficient
to merit their remaining separate elements, as I can see
both sides of that  argument, and feel no affinity for either.

However, on the question of whether a duple is best done
as a list or not.  Well, it is clearly something that can rarely
be embedded inside a paragraph, so trying to make a
duple an inline element seems non-useful.

Duples will often be parts of a list, and that makes useful
the ability  to be put into a list without putting them into
an <li> whose only function would be as a container
for the duple. Therefore duples should have the ability
to be placed directly into a list.  Since a list is unlikely
to contain both duple and non-duple items, a separate
list type for duple lists seems to desirable.

The only remaining question this becomes: "Are non-list
duples common enough to merit allowing them to be used
outside of a duple list instead of using one duple duple lists.

[1] duple - consisting of or involving two parts or
    components usually in pairs

Received on Saturday, 15 November 2003 18:45:37 UTC