Re: Generic LIST Element

Daniel W. Connolly ([email protected])
Thu, 03 Aug 1995 18:03:22 -0400


In message <[email protected]>, Michael J Hannah writes:
>
>Personally, I believe that you get CONSIDERABLY more expressive power
>than you currently have. For me as a document composer, the ability to
>have control over the list ITEM heading is worth the bother. Plus,
>having a general purpose autonumbering scheme is, for me, WELL worth
>the bother. Others have mentioned the expanding outline capability.
>That is not of interest to me, but is an expressive power that we do
>not already have at the control of the document composer, and which
>this proposal provides. For them (see message from
>[email protected] sent on Thu Aug 3 06:28:10 1995) it is worth
>the bother. And further, the bother (or hassle) is not (IMHO) that
>great, nor is the idiom that different.

OK, now that I look at it more closely, I see that there is some
novelty in the proposal. But why throw out the existing markup? Why
not just add to it?

|Rationale
|
|I believe that modifying the list concept to a single generic element
|will eliminate the current and future need for differently named HTML
|elements to identify different ways to present lists

The distinction between <ol>, <ul>, and <dl> is not just presentation,
if you ask me. They are distinct communications idioms.

So allow me to suggest alternatives to your examples in
http://www.sandia.gov/sci_compute/lists.html

|Definition List

leave it as is. Clearly, this example shows no novelty.

|Menu List

MENU/DIR arguably never belonged in HTML. The cited html3-ism:

<UL PLAIN>

looks happy to me. After this example, you write:

|Comments
|
| No PLAIN attribute is required, simply the absence of any LIH
| elements. This is the simplest type of list, and is the simplest
| markup.

This is just bad language design, if you ask me. Clearly, bulleted
lists are the most common _usage_, hence it should have the simplest
markup. I think you're guilty of thinking too much like a programmer
-- especially in this case -- but throughout this proposal.

|Ordered List
|
|Current Ordered List Mechanism
| <OL>
| <LI>Get in boat.
| <LI>Untie from dock.
| <LI>Put up sail.
| </OL>
|Proposed Ordered List Mechanism
| <LIST>
| <LI><LIH><NUM SEQNUM=1>. </LIH>Get in boat.
| <LI><LIH><NUM>. </LIH>Untie from dock.
| <LI><LIH><NUM>. </LIH>Put up sail.
| </LIST>

Ack! Clearly a loss.

| <LIST>
| <LI><LIH>Step <NUM SEQNUM=1>. </LIH>Get in boat.
| <LI><LIH>Step <NUM>. </LIH>Untie from dock.
| <LI><LIH>Step <NUM>. </LIH>Put up sail.
| </LIST>

so now we get to something that's not expressible in HTML 2.0.

The <NUM> element might make an interesting proposal by itself,
without all the other noise. So we might write:

<ul plain>
<LI>Step <NUM SEQNUM=1>. Get in boat.
<LI>Step <NUM>. Untie from dock.
<LI>Step <NUM>. Put up sail.
</ul>

but then you lose some of the alignment. So we might write:

<dl compact>
<dt>Step <NUM SEQNUM=1>.<dd> Get in boat.
<dt>Step <NUM>. <dd>Untie from dock.
<dt>Step <NUM>. <dd>Put up sail.
</dl>

The tricky part about NUM is when the <num> element occurs much before
the element it refers to. It introduces two-pass formatting (if you've
got a way around that, you should definitely put it in the proposal).

| <LIST>
| <LI><LIH><LD></LIH>Fruit
| <LIST>
| <LI><LIH><LD></LIH>Bananas
| <LI><LIH><LD></LIH>Pears
| <LI><LIH><LD></LIH>Apples
| </LIST>
| <LI><LIH><LD></LIH>Nuts
| <LIST>
| <LI><LIH><LD></LIH>Pecans
| <LI><LIH><LD></LIH>Walnuts
| <LI><LIH><LD></LIH>Cashews
| </LIST>
| </LIST>

Ack! Please no! :-)

| <LIST>
| <LI><LIH><IMG HREF="banana.gif"></LIH>Bananas
| <LI><LIH><IMG HREF="pear.gif"></LIH>Pears
| <LI><LIH><IMG HREF="apple.gif"></LIH>Apples
| </LIST>

This one needs addressing. But isn't the obvious markup already in the
HTML 3 draft?

<ul>
<LI src="banana.gif">Bananas
<LI src="pear.gif">Pears
<LI src="apple.gif">Apples
</LIST>

| Successively Revealed Outlines List

Aside from tricks with <num>, this reduces to some mechanism for
hiding portions of a document. Easily expressible in stylesheets
in combination with the class attribute. The HIDE attribute is
an alternative I could live with.

Dan