Re: a compromise on tables, etc.

• Mail folder: WWW Talk Oct 93-present
• Next message: Chris Adie: "Re: Synchronized..."
• Previous message: Dave_Raggett: "Re: X Mosaic, FTP and PASV"
• In-reply-to: Jay C. Weber: "a compromise on tables, etc."
• Reply: Dale Dougherty: "Re: a compromise on tables, etc."

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9312031829.AA27795@manuel.hpl.hp.com>
Subject: Re: a compromise on tables, etc.
To: weber@eit.COM
Date: Fri, 3 Dec 93 18:29:16 GMT
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Jay C. Weber writes:

> We've seen a couple applications developers beg for HTML+ table support
> in browsers, and we've seen browser developers uses tables as the main
> example of the impractical side of HTML+.  Being a little bit of both
> sides I'll suggest a compromise.  How about a BOX tag that works like
> this:

>  <BOX size=20>
>  This is some text to be put in the box.
>  </BOX>

I think we should go for proper tables. They are actually quite easy
to implement, and I intend to release an X11 browser which supports
them in the early spring.

Dave Raggett

p.s. there are three steps to handling tables

   a) determine number of columns and their min/max widths
      (you don't need to be accurate for the max values)

   b) assign widths for current window size

   c) render each cell in turn - you need a way of setting the
      left and right margins (but all browser can do this can't they?)
      its then just like normal rendering.

For efficiency, I do all three steps once and generate a paint stream
which is then interpreted to paint each text line to the window.
Splitting (a) and (b) means you can avoid redoing (a) when users
change the size of the window - probably not worth the extra effort.