Proposal: List attributes-- <UL>, <OL>, <LI>

Charles Peyton Taylor wrote:
>Okay, after looking at the DTD (they make more sense the 
>more you look at them)  I see less and less of a reason 
>not to let images be used as bullets in some future 
>version of HTML, other than the fact that Marc and Bill 
>don't support them (yet).

  [ proposal and commentary on adding SRC= and other attributes 
    to lists in the HTML 3.2 DTD ]

> Comments?

   Thank you, thank you!  This is the kind of specific proposal
that Dan has been calling for.  I'd only like to observe that
these proposals are not new, but have been successfully tested
in on the Web in documents, browsers, and validators for a year
or more.  I have been using <UL SRC= > and <UL PLAIN> according
to the HTML 3.0 draft.  The "market leaders," of course, do not
recognize these attributes, but they display the lists in their
default manner.  UdiWWW displays both of these completely and
correctly: with custom image bullets in the first case, and with
no bullets in the second.  Lynx 2.5 does not display inline
images, so it successfully substitutes its generic bullets in
the first case, and successfully displays no bullets in the 
second.  I would further note that neither of these browsers
is limited to the enhancements of the expired HTML 3.0 draft--
UdiWWW supports body-colors, <CENTER>, and many other features
of the 3.2 proposal, as well as Frames and other vendor 
extensions.  Lynx 2.5 is updated almost daily, and supports
Netscape's <OL TYPE= > attributes (proposed for 3.2, but not
yet accurately described in the DTD) along with nearly every
other enhancement that's ever been described or implemented
by anyone, if it can be implemented in a character-mode browser!

   While this "supporting evidence" is only anecdotal, it comes
the from personal experience of a real web author with real
documents on the real Web, viewed with a variety of real user
agents.  I can also verify, from reading and participating in
the authorship newsgroup, that (1) a large number of real authors 
are asking for the attributes in CPT's proposal, (2) in the absence
of these attributes, many authors resort to ugly hacks that 
neither degrade well, nor accurately describe their content.

   I see the greatest strength of the proposed 3.2 materials to
be their simplicity.  While criticizing its deficiencies, and 
proposing enhancements, I would suggest confining changes to 
those that are essential *as HTML* (though there will surely
be differing opinions on this); I'd be reluctant to support 
many "brand-new" tags and attributes, without convincing real-
life experience.  The expired HTML 3.0 draft consititutes a
valuable source for such enhancements (field tested in a small
but important market segment), but these should not be adopted
wholesale without convincing arguments.

   Now to the specifics of CPT's proposal.  
Unordered lists <UL>: 

 Wilbur has: 
 HTML 3.0 has:
    ID= , LANG= , CLASS= , CLEAR= , MD=  [common to block elements]
    as well as the optional <LH> list header element.

 CPT proposes: 

  Again, I'd give preference to enhancements that have been successfully
test and are in current use (in at least a small minority of documents).    
The most glaring omission is <UL PLAIN>.  If not implemented, it's
harmless; if implemented it obviates the need for a dozen hacks,
including the abuse of <DL>, <DD>, and <BR> and unnecessary tables,
in thousands of current documents.

  And, while I applaud the inclusion of SRC= as an HTML attribute,
I'm not convinced that the "fine-tuning" offered by HEIGHT, WIDTH,
HSPACE, and VSPACE are worth the added complexity.  A case can be
made for them, as well as for ALT= , but I'd prefer to leave the
details to style sheets and proceed with getting PLAIN and SRC= 
into the specs and implemented by browsers.  

  In addition, I'd like to see at least some of the generalized
block attributes preserved: CLASS= and ID= are currently used in
documents, will soon be used wth style sheets, and are potentially
used by searchers and indexers.  I'd hate to see them temporarily
removed for no better reason than that two popular browsers have
not yet found anything to do with them.  I also believe strongly
that the CLEAR= attribute should be generalized to block elements,
to avoid misuse of the line break element <BR>.  Any block element
should be able to clear the margins, without adding a redundant <BR>.

   I realize that others will have their own priorities, but I'd
like to offer a conservative and minimal addition to the current
Wilbur proposal:
    CLASS= , ID= , CLEAR=               [common to block elements]

   While a case can be made for other attributes, and for the 
list header <LH>, I believe this maintains the "lean, clean"
character of the Wilbur proposals while adding only the most
essential enhancements that have been tested and are in use.

Likewise for <OL> Wilbur has: 
 HTML 3.0 has:
    ID= , LANG= , CLASS= , CLEAR= ,      [common to block elements]
    as well as the optional <LH> list header element.

I suggest: 
    CLASS= , ID= , CLEAR=               [common to block elements]

   Some still prefer SEQNUM and CONTINUE to TYPE and START, but
I'd bow to the currency of TYPE, with its flexibility in creating 
simple outlines with letters or numbers.  Further details can be 
treated in style sheets.

   Finally, list items <LI>, which are used in both kinds of lists.

 Wilbur has: 
    TYPE= , VALUE= 
 HTML 3.0 has:
    ID= , LANG= , CLASS= , CLEAR= , MD=  [common to block elements]

 CPT proposes: 
    TYPE= ,  VALUE=

Again, in the interest of simplicity, I'd accept"
    TYPE= , VALUE= , SRC=

    Obviously, the distinction between OLStyle and ULStyle attributes
in the Wilbur DTD is useful.  I leave it to others to decide if the
generalized block attributes CLASS, CLEAR, and ID belong in <LI>.

    I realize that much of this ground has been gone over before, 
and I acknowledge the reluctance of some ERB members to open up
cans of splippery and elusive worms.  I am not a programmer, nor
an SGML wizard, only an author interested in a flexible structure-
based markup that can be displayed clearly and attractively with
only minimal alterations to standards and browsers.  To Charles's
suggestions I have added only <UL PLAIN> and some acknowledgment
of generalized block attributes, while sacrificing details that could
be defended, but I wouldn't regard as essential.  Your comments are

Warren Steel              
Department of Music              University of Mississippi

Received on Friday, 17 May 1996 11:12:32 UTC