Plugin Removed

This plugin has been removed because the definitions plugin by Pavel Vitis does the same thing… better! Thanks Pavel for making it work. — stephanec 2005-08-18 01:13

There is my version of this plugin, which works with markup inside descriptions and produces correct HTML.
Pavel Vitis

And there's a third version supporting all list variants defined by (X)HTML.
— Matthias Watermann 2005-08-24

Actually my plugin does support all variants of markup you suggested, it was just missing in the examples.
Pavel Vitis

Of course I tried your plugin before I started to write my own. Unfortunately it doesn't work as intended. Your example

  = Item 1 : Definition of item 1.
  = Item 2 : Definition of item 2.
  = : Second definition of item 2.
  = Item 3 : Definition of item 3.
  = Item 4 : 
  = Item 5 : 
  = Item 6 : Definition of items 4 through 6.

is rendered by your plugin (as of 2005-08-17) as

<dl>
  <dt> Item 1 </dt><dd> Definition of item 1.</dd>
  <dt> Item 2 </dt><dd> Definition of item 2.</dd>
  <dt> </dt><dd> Second definition of item 2.</dd>
  <dt> Item 3 </dt><dd> Definition of item 3.</dd>
  <dt> Item 4 </dt><dd> </dd>
  <dt> Item 5 </dt><dd> </dd>
  <dt> Item 6 </dt><dd> Definition of items 4 through 6.</dd>
</dl>

which is just wrong:
* The Second definition of item 2 is in fact the first definition of an “anonymous” term consisting of a space.
* The items 4 and 5 both have a definition consisting of a space character, which is quite different from having no description.
* The text Definition of items 4 through 6. is plain wrong, in fact it's the one and only definition of item 6.

Your updated version (as of 2005-08-25) produces this

 <dl>
	<dt> Item 1 </dt>
		<dd> Definition of item 1.</dd>
	<dt> Item 2 </dt>
		<dd> Definition of item 2.</dd>
		<dd> Second definition of item 2.</dd>
	<dt> Item 3 </dt>
		<dd> Definition of item 3.</dd>
	<dt> Item 4 </dt>
		<dd> </dd>
	<dt> Item 5 </dt>
		<dd> </dd>
	<dt> Item 6 </dt>
		<dd> Definition of items 4 through 6.</dd>
</dl>

While this is improved insofar as the empty definition terms (<dt>) are omitted there's still the bug with empty definition data (<dd>) markup.

Apart from that I haven't been able to figure out how to embed other elements (like lists or tables or just multiple paragraphs (not linebreak <br/>) in a data definition. While that may be completely my fault, it would be helpful if you could add some documentation about how to do that.
— Matthias Watermann 2005-08-25 19:03

You don't need any documentation how to do that because logic says that it's not possible to embed such markup if I am relying on \n as an ending tag. As of empty <dd></dd>, I didn't see this as a problem at all since these cases are rendered by all browsers correctly. Pavel Vitis

Ah, I see. And I'm sure you'll agree, that's not the visual rendering of some browser which gets the point, but the correct formal markup of what was meant in the first place. And as I demonstrated above an empty (or space-only) definition has a completely different meaning from a non-existing one. That's why I stated that your plugin unfortunately doesn't support all the possible combinations and in fact produces a wrong HTML markup.
— Matthias Watermann 2005-08-26 22:17

I wonder if its possible that all your definition list plugins could use the same syntax? I wouldn't think there is any advantage to any one installing more than one definition list plugin. A common syntax seems sensible — Christopher Smith 2005-08-25 02:25

It looks like both of the definition list plugin authors have created an original syntax for their plugins. Perhaps we should look at existing syntaxes (and there are many) and choose the one that seems the most visually logical in a piece of unparsed text. — ta' Lajzar 2005-08-25 04:03

I looked at the comparison page where only mediawiki is mentioned. Its syntax doesn't seem very intuitive (at least to me) and it doesn't allow for correctly marking up all four variants (1:1, 1:n, n:1, n:n). So I ended up with my ?? term :: definition !! syntax. In case you know about better alternatives, please let me know.
— Matthias Watermann 2005-08-24 13:48

How about …

Dokuwiki markup                          HTML translation
  ; definition term : definition data    <dt>definition term</dt><dd>definition data</dd>
  ; definition term                      <dt>definition term</dt>
  : definition data                      <dd>definition term</dd>

  All definition list lines should start with standard
  dokuwuki list indent of an even number of spaces

Contiguous lines of any combination of definition list markup at the same indent level surrounded by a single <dl> </dl> pair. When a subsequent line is indented further, the closing tag on the previous line should not be rendered until after the next line at the original indent level or there is no more list data. e.g.

  ; definition term : definition data     <dl><dt>definition term</dt><dd>definition data
    ; definition term                       <dl><dt>definition term
    : definition data                         </dt><dd>definition data
    : definition data                         </dd><dd>definition data
    ; definition term                         </dt><dd>definition term
                                          </dt></dl></dd></dl>

— Christopher Smith 2005-08-25 20:51

One thing that occurred to me this morning. A definition list is essentially an unordered list that has a special rules. It can only be two levels deep (the <dt> level and the <dd> level). Given that, perhaps everyone in every wiki has approached this from the wrong direction. perhaps a markup similar to that used in a more usual list would be appropriate, but with a different character. This would make the markup much more human-readable, and keep it consistent with other list markup formats. For example:

Target HTML:

<dl>
  <dt>Item 1</dt>
    <dd>First definition of item one.</dd>
    <dd>Second definition of item one.</dd>
    <dd>Third definition of item one.</dd>
  <dt>Item 2</dt>
    <dd>Definition of item two.</dd>
  <dt>Item 3</dt>
  <dt>Item 4</dt>
    <dd>Definition of items three and four.</dd>
</dl>

markup used:

  ; Item 1
    ; First definition of item one.
    ; Second definition of item one.
    ; Third definition of item one.
  ; Item 2
    ; Definition of item two.
  ; Item 3
  ; Item 4
    ; Definition of items three and four.

— ta' Lajzar 2005-08-25 23:56

Not sure, what you're meaning by “levels deep”. If you meant to say only the <dt> and <dd> tags are allowed as immediate childs, then it's true. But please note that the definition data may contain other elements (like e.g. another <dl>/<ol>/<ul> or just several paragraphs etc.) and insofar as the “depth” of a definition list is theoretically infinite.
— Matthias Watermann 2005-08-28

Yes, you understood me right. But the weakness you point out in my proposed syntax (can't handle paragraphs) is equally true of regular lists too, but no one has suggested changing those. As foy your other point, I'm not sure nesting another <dl> inside a definition data field makes sense semantically anyway. I believe my proposed syntax does allow for a regular <ol> or <ul>, but again, I don't think those make much sense nested inside a <dl>. — ta' Lajzar 2005-08-28 17:06

Well, I can image a couple of scenarios where such a nesting would be not only helpful but as well be the only adequate structure. For instance see →Lorem ipsum where I demonstrate how to nest DL/OL/UL inside a definition list.
And about the OL/UL constructs: I'm sure it's only a matter of time until someone will replace the currently built in parser by a plugin supporting nesting of other block elements inside a list item.
— Matthias Watermann 2005-08-30 19:11

See lists for un/ordered lists that allows for embedding other block elements in list items.
— Matthias Watermann 2005-09-04 22:05

From the W3 website:

<DL>
  <DT>Center
  <DT>Centre
    <DD> A point equidistant from all points on the surface of a sphere.
    <DD> In some field sports, the player who holds the middle position on the field, court, or forward line.
</DL>

Seems a properly written definition list parser will also need to handle the 2:2 case.

Its actually an n:n case. Both the proposals above support n:n.