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

>>> Warren Steel <mudws@mail.olemiss.edu> 05/17/96 07:12am >>>
>Charles Peyton Taylor wrote:
<snip!>

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

Exactly!  I've been using <ul=plain> just for those people
who might see my HTML with a browser that supports it.

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

Actually, I forgot about PLAIN when I was writing that
up yesterday.  It would be very useful, and I may 
re-write what I wrote yesterday to include it.

>obviates the need for a dozen hacks, including the abuse of <DL>,
><DD>, and <BR> and unnecessary tables, in thousands of current
>documents.

Yes, I've been using the Harvest search engine at our
site
(http://www.nps.navy.mil:80/Harvest/brokers/nps_harvest/query.html)
It understands a good bit of SGML.  Between that and 
style sheets, I'm seeing more and more reasons why 
HTML should be marked up according to content.  (Ie.
<LI> as opposed to <BQ> or <DD>).

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

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. (Hspace and 
vspace aren't so important to me, but they may be
to others.)



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

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.


>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'd be satisfied if clear=right and clear=all would be 
implemented in <BR>.  But they should be in all block
elements, I'm sure.

<snip!>

>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 13:10:30 UTC