10 Lists

Contents

  1. Introduction to lists
  2. Unordered lists (UL), ordered lists (OL), and list items (LI)
  3. Definition lists: the DL, DT, and DD elements
    1. Visual rendering of lists
  4. The DIR and MENU elements

10.1 Introduction to lists

HTML offers authors several mechanisms for specifying lists of information. All lists must contain one or more list elements. Lists may contain:

The previous list, for example, is an unordered list, created with the UL element:

<UL>
<LI>Unordered information. 
<LI>Ordered information. 
<LI>Definitions. 
</UL>

An ordered list, created using the OL element, should contain information where order should be emphasized, as in a recipe:

  1. Mix dry ingredients thoroughly.
  2. Pour in wet ingredients.
  3. Mix for 10 minutes.
  4. Bake for one hour at 300 degrees.

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:

Lower cost
The new version of this product costs significantly less than the previous one!
Easier to use
We've changed the product so that it's much easier to use!
Safe for kids
You can leave your kids alone in a room with this product and they won't get hurt (not a guarantee).

defined in HTML as:

<DL>
<DT><STRONG>Lower cost</STRONG>
<DD>The new version of this product costs significantly less than the
previous one!
<DT><STRONG>Easier to use</STRONG>
<DD>We've changed the product so that it's much easier to use!
<DT><STRONG>Safe for kids</STRONG>
<DD>You can leave your kids alone in a room with this product and
they won't get hurt (not a guarantee).
</DL>

Lists may also be nested and different list types may be used together, as in the following example, which is a definition list that contains an unordered list (the ingredients) and an ordered list (the procedure):

The ingredients:
The procedure:
  1. Mix dry ingredients thoroughly.
  2. Pour in wet ingredients.
  3. Mix for 10 minutes.
  4. Bake for one hour at 300 degrees.
Notes:
The recipe may be improved by adding raisins.

The exact presentation of the three list types depends on the user agent. We discourage authors from using lists purely as a means of indenting text. This is a stylistic issue and is properly handled by style sheets.

10.2 Unordered lists (UL), ordered lists (OL), and list items (LI)

<!ELEMENT UL - - (LI)+                 -- unordered list -->
<!ATTLIST UL
  %attrs;                              -- %coreattrs, %i18n, %events --
  >
<!ELEMENT OL - - (LI)+                 -- ordered list -->
<!ATTLIST OL
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

Start tag: required, End tag: required

<!ELEMENT LI - O (%flow;)*             -- list item -->
<!ATTLIST LI
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

Start tag: required, End tag: optional

Attribute definitions

type  =  style-information [CI]
Deprecated. This attribute sets the style of a list item. Currently available values are intended for visual user agents. Possible values are described below (along with case information).
start = number [CN]
Deprecated. For OL only. This attribute specifies the starting number of the first item in an ordered list. The default starting number is "1". Note that while the value of this attribute is an integer, the corresponding label may be non-numeric. Thus, when the list item style is uppercase latin letters (A, B, C, ...), start=3 means "C". When the style is lowercase roman numerals, start=3 means "iii", etc.
value = number [CN]
Deprecated. For LI only. This attribute sets the number of the current list item. Note that while the value of this attribute is an integer, the corresponding label may be non-numeric (see the start attribute).
compact [CI]
Deprecated. When set, this boolean attribute gives a hint to visual user agents to render the list in a more compact way. The interpretation of this attribute depends on the user agent.

Attributes defined elsewhere

Ordered and unordered lists are rendered in an identical manner except that visual user agents number ordered list items. User agents may present those numbers in a variety of ways. Unordered list items are not numbered.

Both types of lists are made up of sequences of list items defined by the LI element (whose end tag may be omitted).

This example illustrates the basic structure of a list.

<UL>
   <LI> ... first list item...
   <LI> ... second list item...
   ...
</UL>

Lists may also be nested:

DEPRECATED EXAMPLE:

<UL>
     <LI> ... Level one, number one...
     <OL> 
        <LI> ... Level two, number one...
        <LI> ... Level two, number two...
        <OL start="10"> 
           <LI> ... Level three, number one...
        </OL> 
        <LI> ... Level two, number three...
     </OL> 
     <LI> ... Level one, number two...
</UL>

Details about number order. In ordered lists, it is not possible to continue list numbering automatically from a previous list or to hide numbering of some list items. However, authors can reset the number of a list item by setting its value attribute. Numbering continues from the new value for subsequent list items. For example:

<ol>
<li value="30"> makes this list item number 30.
<li value="40"> makes this list item number 40.
<li> makes this list item number 41.
</ol>

10.3 Definition lists: the DL, DT, and DD elements

<!-- definition lists - DT for term, DD for its definition -->

<!ELEMENT DL - - (DT|DD)+              -- definition list -->
<!ATTLIST DL
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

Start tag: required, End tag: required

<!ELEMENT DT - O (%inline;)*           -- definition term -->
<!ELEMENT DD - O (%flow;)*             -- definition description -->
<!ATTLIST (DT|DD)
  %attrs;                              -- %coreattrs, %i18n, %events --
  >

Start tag: required, End tag: optional

Attributes defined elsewhere

Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

Here is an example:

  
<DL>
  <DT>Dweeb
  <DD>young excitable person who may mature
    into a <EM>Nerd</EM> or <EM>Geek</EM>

  <DT>Hacker
  <DD>a clever programmer

  <DT>Nerd
  <DD>technically bright but socially inept person

</DL>

Here is an example with multiple terms and descriptions:

<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>

Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.

10.3.1 Visual rendering of lists

Note. The following is an informative description of the behavior of some current visual user agents when formatting lists. Style sheets allow better control of list formatting (e.g., for numbering, language-dependent conventions, indenting, etc.).

Visual user agents generally indent nested lists with respect to the current level of nesting.

For both OL and UL, the type attribute specifies rendering options for visual user agents.

For the UL element, possible values for the type attribute are disc, square, and circle. The default value depends on the level of nesting of the current list. These values are case-insensitive.

How each value is presented depends on the user agent. User agents should attempt to present a "disc" as a small filled-in circle, a "circle" as a small circle outline, and a "square" as a small square outline.

A graphical user agent might render this as:

A possible rendering of a discfor the value "disc"
A possible rendering of a circlefor the value "circle"
A possible rendering of a squarefor the value "square"

For the OL element, possible values for the type attribute are summarized in the table below (they are case-sensitive):

Type Numbering style
1 arabic numbers 1, 2, 3, ...
a lower alpha a, b, c, ...
A upper alpha A, B, C, ...
i lower roman i, ii, iii, ...
I upper roman I, II, III, ...

Note that the type attribute is deprecated and list styles should be handled through style sheets.

For example, using CSS, one may specify that the style of numbers for list elements in a numbered list should be lowercase roman numerals. In the excerpt below, every OL element belonging to the class "withroman" will have roman numerals in front of its list items.

<STYLE type="text/css">
OL.withroman { list-style-type: lower-roman }
</STYLE>
<BODY>
<OL class="withroman">
<LI> Step one ...  
<LI> Step two ...
</OL>
</BODY>

The rendering of a definition list also depends on the user agent. The example:

<DL>
  <DT>Dweeb
  <DD>young excitable person who may mature
    into a <EM>Nerd</EM> or <EM>Geek</EM>

  <DT>Hacker
  <DD>a clever programmer

  <DT>Nerd
  <DD>technically bright but socially inept person
</DL>

might be rendered as follows:

Dweeb
       young excitable person who may mature into a Nerd or Geek
Hacker
       a clever programmer
Nerd
       technically bright but socially inept person

10.4 The DIR and MENU elements

DIR and MENU are deprecated.

See the Transitional DTD for the formal definition.

Attributes defined elsewhere

The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements.



What's the goal of this project ?

The e:doc Project gives the users of SGML-based text systems the possibility to design their documents in a nearly WYSIWYG environment (=What You See Is What You Get).

It's on the way to become a scientific document processor (that's something like a document centered word processor) that is

  1. free in the sense of OPEN SOURCE
  2. free of charge
  3. free in the choice of the operating system
  4. free in the choice of the target systems
  5. easy to adapt to the users needs
  6. easy to add functionality by its plug-in system

e:doc is not a layout tool like most of our modern word processors are, it focuses more on a structured approach to the document content.

The way e:doc is distributed now, it gives those who write scientific, technical or other larger text projects the oportunity to write in a modern GUI (graphical user interface) AND use the power of structured document tools like LaTeX or HTML.


Which operation systems is the project based on ?

e:doc is based on several free products that are available on a large scape of operating systems.

This enables e:doc to run on Windows95/98/2000, WindowsNT, Linux, several U*NIXes, MacOS, BeOS, OS/2 and maybe some other systems that provide a graphical user interface.

You should check first, if all needed programs are available on your platform and have the required version number.


Where can I get the files ?

To get it run, you will need several other programs to be installed on your system first. These programs are listed in the next section.

One of the main features of e:doc is, that the same source files run on all supported operating systems. This allows us (until now "me") to focus only on one version of source code and still supporting a wide range of operating systems.

But different systems use different compression methods, so we provide the e:doc -files in several packages, all compressed by a famous compression program. Though they are plain text files and gif-pictures, there is adifference between the supported operating systems. A text file for LINUX is not the same as a text file for WINDOWS.

Click here to get to the download page.


What do I need to run the program ?

To run the program you will need Perl, Perl/Tk and (in most cases) LaTeX.

If you are working on a LINUX or any other U*nix box, those 3 packages should be available in your distribution. You will only have to check, that you have the right version.

You will need Perl 5.005 or higher, Perl/Tk 800.020 or highter and LaTeX 2e.

Below, I will list some distributions, I have done some testing with:

For Win32:

How to install Perl/Tk for AS-Perl ?

go to www.activestate.com and get perl. Install it. Change to the DOS prompt, type 'ppm', next type 'install tk' and wait until it's finished (May take a few minutes, depending on the speed of your internet connection)

For Linux:

  • Perl from CPAN (should be already included in your LINUX distribution).
  • Perl/Tk from CPAN (should be already included in your LINUX distribution).
  • teTeX. (should be already included in your LINUX distribution)
  • Optional: Ghostscript or gs (should be already included in your LINUX distribution).

Other operating systems:

  • Perl, Perl/Tk: look at CPAN.
  • LaTeX: look at CTAN.

How much does this stuff cost ?

Nothing !

This is a freeware project that is licensed by the GNU General Public Licence (GPL).

Because this is free software, I do NOT grant ANYTHING to the user. I am not responsible for any loss of data and/or other valuable things caused by using this UNSTABLE software.


I want to join the project ! How can I cooperate ?

What/whom do we need ?

  1. Perl/Tk programmers: For coding some new dialog windows or do some work in the core layout engine.
  2. Perl programmers: Establish better (faster) algorithms and regexes in many places.
  3. LATEX specialists: Teach the application what LaTeX commands exist and how they have to look by enlarging the files "edoc.int" and "LATEX.out" .
    And by doing this we expect some feedback what additional commands and structures are needed to make the style-definitin-language powerfull enough to describe all of LaTeX possibilities.
  4. HTML gurus: Do the same for the HTML-backend and maybe make this site look better.
  5. Others: Testing and documentation.

In which direction should we go ?

In an OPEN SOURCE project you can never tell where the finishing line is, but I am planning some special functions (after the basic core functionality is established) that will distinguish e:doc from all other text processors.

  1. Calculating fields: This means that you can set fields in the text that can contain formulas and references to other fields. For example you can summarize a table in one field and calculate the mean value somewhere later in the text. When you change something in the table, the mean value in the text gets its new value automatically.
  2. Macro language:To allow realization of things like TableOfContents or Footnotes in poorer languages like HTML, this macro language (I will use basically Perl) will be able to automatically produce and format text parts.
  3. PlugIns:The second step for Plug-Ins will be, that they will be automatically registered into the e:doc system and can be embedded into the document as well.
  4. Interactive configuration: Provide some configuration tools to allow the user to adopt his e:doc to his personal needs by mouse and Drag&Drop.
  5. Bibliography and References: Offer the user a system to manage literature and automatically insert and update citations and references inside his document.
  6. Structuring tools: Allows the user to restructure his document, temporary hide parts of the document and to build larger text projects from several files.

There are even future dreams (usually called concepts) of much bigger thing like a Perl & Tk based scientific office-pack. This could consist of a spreadsheet, a database(-frontend), a literature database, a project manager and a spell checker, all glued together by Perl & Tk as macro language and the OLE-like PlugIn system established in e:doc.


Let's see the screenshots first !

Click here.



This site is designed with GNU XEmacs.

Pictures are produced with The GIMP.

It's best viewed with any Browser.