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

Warren Steel <mudws@mail.olemiss.edu> wrote:
>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.  
>[...]
>
>I suggest: 
>_________________________________________________________________
><OL>  
>    CLASS= , ID= , CLEAR=               [common to block elements]
>    COMPACT, TYPE= , START=
>_________________________________________________________________
>
>   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.
>[...]

	START is identical to SEQNUM.  The latter is the longer-standing
HTML+ attribute for specifying the initial value for an ordered list,
and the former is simply a reinvention of that wheel as we'll.  Clients
such as Lynx, UdiWWW, etc. treat them as synonyms, so it doesn't matter
which one is used in Wilbur, but if it were to follow the traditions
of the Web, it would at least mention the other with a suggestion that
clients also recognize it for maximum compatibility and effectiveness.

	TYPE is a Netscape invention, and a really good idea, albeit
that it depends on case-sensitive parsing of normally case-insensitive
attribute values.  But it is not the same as CONTINUE.  The latter
indicates whether to continue the count from the previous OL. It
also has been implemented in Lynx, UdiWWW, etc., and is very useful
when used in nested lists, or when a list is terminated to insert
another type of block, and then another list is started which is
a logical continuation of the preceding.  One can create the same
effect and semantic connotation in the display by counting previous
LIs, hoping one's count was accurate, and using START or SEQNUM for
the new list, but CONTINUE is easier, does not require one to re-count,
and edit all the START or SEQNUM values, when LIs are added or deleted
from preceding lists, and is more meaningful for indexers.  Also,
CONTINUE does not break any clients which failed to implement it.

	I hope the W3C will be permitted to restore the, for many of
us, sorely missed CONTINUE attribute.  If it would help to give it
another name, that would still be better than bannishing it from
the specs.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Friday, 17 May 1996 15:27:10 UTC