More on list attributes, <HR>

Charles posted excellent proposals for permitted attributes in <UL>, 
<OL>, and <LI>.  I proposed a slightly simpler system, on the grounds
that it might keep the spec and the implementation simpler.  Both 
allowed for a SRC= attribute in <UL> and <LI>, providing "custom
bullets," as in the expired HTML 3.0 draft.  Some responses:
      *     *     *

Chris Josephes <cpj1@winternet.com>:
>There's always the chance that the author will want control over height, 
>width, and spacig of the bullet.  But I still think that this sort of 
>thing would be better if it was handled by stylesheets....

>I'd vote against ALT.  It could either get really abused, or ignored like 
>ALT always has been by some authors out there....

>Also, if we're talking about improving lists, why not talk about wrapping 
>lists into columns and list header elements?...

      *    *    *
Charles Peyton Taylor <CTaylor@wposmtp.nps.navy.mil>:
>I don't think adding HEIGHT, WIDTH, HSPACE, and 
>VSPACE are really adding much complexity.  I would 
>imagine that the functions used to draw images on 
>the screen when they are specified by <IMG> would be 
>used to draw images when they are specified by <UL>.
>I've used HEIGHT and WIDTH in my documents, and I
>have seen a *DRAMATIC* increase in the amount of time
>the text is presented to the reader by those browsers
>that support it.  I would *NOT* recommend that SRC
>be added to <LI> or <UL> without them. 

>CLASS I can see as being useful, and at least somewhat
>backward compatible.  ID, on the other hand, was used
>in HTML 3 for creating an anchor, a lot like <a Name="">
>I don't think ID should be in Cougar until browsers
>support it.

     *     *     *
marcush@crc.ricoh.com (Marcus E. Hennecke):
>Two things come to mind:
>1. Wilbur does also have the MENU element, which was intended to
>   display an unbulleted list. Of course, we all know that only
>   few browsers get that right, but at least it's in there.
>   (Actually, given that the most popular browsers, on which Wilbur
>   supposedly is based, don't correctly render MENU and DIR, these
>   two elements could probably be deprecated)
>2. Since we already have TYPE, would <UL TYPE=EMPTY> be
>   satisfactory? That way we wouldn't need a new attribute.

         *     *     *
Foteos Macrides <MACRIDES@sci.wfbr.edu>:
>	START is identical to SEQNUM...
>	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....
>	I hope the W3C will be permitted to restore the, for many of
>us, sorely missed CONTINUE attribute.  
        *    *     *

   Again, the "Wilbur" documents come from the ERB, and may have at
least the implied consent of the vendors represented there.  This
is a stripped-down, minimal HTML, and the burden of persuasion is
upon those who wish to modify it, especially where it involves added
complexity.  This was the basis of my suggestions: find the essentials.
While some of these items "could" go into style sheets, and may 
eventually be duplicated there, I tried to suggest only what has
been successfully deployed (though not widespread) *as HTML*.

   So I try to be merciless:  as Chris suggests, leave out ALT=
There's plenty of degrading built in.  Columns would be nice, but 
they are barely implemented (if at all); list headers would be 
nice indeed, but I'm trying to keep new *elements* to a minimum.
A possible workaround might be
  <div class=list> <h3>list heading</h3> <ul>...</ul> </div>
And I agree with Chris on the IMG-like attributes for width, 
hspace, etc.  These are bullets, after all, and should be small
and sweet, and not slow things down overmuch.  If vendors want 
to implement them, fine, but let them say so while agreeing to
bring the rest of this modest proposal to life. 

   If Charles says ID= is little used, and of little use,
then let it die, or at least rest in hope of later resurrection.
   Fote is a respected browser developer, and if he can use 
CONTINUE let it remain.  He's right that SEQNUM has "priority" 
over its Netscapish synonym START, but the latter is both 
comprehensible and in use, so go with START, maybe with SEQNUM 
as a permissible alias for validation purposes.
   Marcus has very interesting suggestions.  <UL TYPE=empty> 
might have made it two years ago, but <UL PLAIN> is already
tested, and implemented; all it lacks is the embrace of the 
"market leaders."  A <MENU> is not the same as a <UL PLAIN>,
even though it may occasionally look the same.  If <MENU>
were deprecated, one could still use <UL PLAIN>, but the 
but not every plain list is a menu.  

   Please excuse my "keeping score"; I realize that each of us
has his or her priorities in the revision process; I just want
to avoid losing sight of the barest essentials.  So, in all
humility, before 24 hours have passed, here's a revised 
suggestion.  I don't have the experience or technical skill to 
express it in the proper language, but I hope it can still be 
discussed, and if approved, then incorporated. 


_________________________________________________________________
<UL>  
    CLASS= , CLEAR=                     [common to block elements]
    PLAIN, COMPACT, TYPE= , SRC=

<OL>  
    CLASS= , CLEAR=                     [common to block elements]
    COMPACT, CONTINUE, TYPE= , START=

<LI>  
    TYPE= , VALUE= , SRC=
_________________________________________________________________

   What about interaction?   <UL SRC="redball.gif" TYPE=square>
If image-loading is on, display the GIF; if not, display the
square symbol; if symbols are not available, the generic text 
bullet.  <LI SRC="blueball.gif"> would override the <UL SRC= >
for that one list item.  

    And, while we're on the subject, let's take a quick look at
the horizontal rule <HR>.  

Wilbur has:
   NOSHADE, ALIGN= , SIZE= , WIDTH=   

HTML 3.0 has
   ID= , CLASS= , CLEAR= , SRC= , MD=

I thinks this is an easy one.  The need was recognized long ago for a
custom rule that degrades to a generic rule, without the awkward
expedient of <IMG SRC="rule.gif" ALT="----------------------------">.
The Netscape/Wilbur attributes add some flexibility, but don't do the 
job.  These attributes refer to an image stored in the browser.  The 
SRC= attribute refers to an external image on a server.  While some 
browsers *can* resize inline images, I'd like to allow <HR SRC= > 
without the added complexity of resizing.  So let me suggest:
 
_________________________________________________________________
<HR>  
    CLASS= , CLEAR=                     [common to block elements]
    NOSHADE, ALIGN= , SIZE= , WIDTH= , SRC= 
_________________________________________________________________

   Now consider this: 
<HR SRC="ropeline.gif" ALIGN=center NOSHADE SIZE=7 WIDTH=350>

  If image-loading is on, use the GIF, aligned as specified, but
ignore the dimensional attributes (which might distort the image).
If image-loading is off, use the generic horizontal rule, aligned
and sized as specified (if possible); if a horizontal rule is not
available, use the text substitute.  I know a case could be made
for other attributes--are they clearly essential, and are they at
least minimally implemented and tested in the real world.  With
skillful and considerate combining of time-tested markup from
both "market leaders" and bold experimenters, perhaps we could
avoid seeing HTML 3.2 (or 3.3) take a giant step backward away
from the utility and flexibility that authors need.

Warren Steel                        mudws@mail.olemiss.edu
Department of Music              University of Mississippi
          URL: http://www.mcsr.olemiss.edu/~mudws/

Received on Friday, 17 May 1996 17:40:47 UTC