Subject: Re: Suggested change to README.html generation: tables for binaries
To: Julian Assange <proff@iq.org>
From: Matthew Orgass <darkstar@pgh.net>
List: tech-pkg
Date: 11/09/1999 12:24:39
On 10 Nov 1999, Julian Assange wrote:

> As a religious lynx/w3 user, it's done with tables, I DON'T. Below

  I checked the lynx change logs and it looks like the minimal table
support was first released with version 2.5 on May 2, 1996. 

  Tables were part of HTML+ in 1993 and were widely implemented, but not
in the HTML 2.0 standard (RFC1866) in late 1995. RFC1942 in May 1996
specified an experimental version of tables which were a superset of HTML+
tables and were not widely implemented until fairly recently (HTML 4). 
Tables were in HTML 3.0 (which was submitted as an Internet Draft in 1994
but never standardized) and HTML 3.2 (recommended by the W3C in January of
1997). 

> I present the appropriate way to do things (this is much more flexible).
> 
> <dl>
> <dt>alpha
> <dd>
> <dl>
> <dt>1.4
> <dd>
> <ul>
> <li>mpg123-O.59q
> <li>mpg123-O.59o
> <li>mpg123-O.59q
> </ul>
> </dl>
> </dl>

  ?  Alpha has only one binary package of mpg123 available, version 0.59q
for NetBSD version 1.4.  As far as I know, there should only ever be one
package version available for each NetBSD version.

> >   This version takes up much less horizontal space then the <PRE> version
> > while still doing some alignment on graphical browsers and looking
> > reasonable on text browsers.  Useing just two columns, one for the port
> > and one for the versions, keeps the text on one screen while still
> 
> This is an egregious hack. lynx, w3, w3m, etc ARE table aware, they just
> render tables either incredibly poorly, or in a way which is extremely
> hard to read.

  True.  A browser that does not implement tables at all would completely
ignore table tags, creating messy output in my table example (but still
useable).  Not that the main NetBSD page uses tables and would be
similarly displayed.

> Whether <PRE> etc renders into something decent is really a shot in the
> dark.

  Not true.  <PRE> is defined as "preformatted text".  While a cell phone
might strip out the extra spaces, any text or graphical browers that does
this is simply broken.  Likewise, any graphical browser that does not
render it in a fixed-width font is broken.  While this behavior is allowed
by the standard, it clearly violates the purpose of the tag.  I do not
know of any browsers that do not render <PRE> correctly (lynx could deal
with it from at least version 2.1 almost six years ago).

Matthew Orgass
darkstar@pgh.net