Re: HTML3 tables

Philippe-Andre Prindeville (philipp@res.enst.fr)
Mon, 5 Dec 94 15:19:07 +0100


Date: Mon, 5 Dec 94 15:19:07 +0100
From: Philippe-Andre Prindeville <philipp@res.enst.fr>
Message-Id: <9412051519.ZM20091@dameron.res.enst.fr>
In-Reply-To: michaelj@relay.relay.com (Michael Johnson)
To: michaelj@relay.relay.com,
        Multiple recipients of list <www-html@www0.cern.ch>
Subject: Re: HTML3 tables

On Dec 2, 15:22, Michael Johnson wrote:
> Subject: HTML3 tables
> I withdraw my objection to VALIGN, seeing as how I implemented it in a couple
> of hours yesterday.

As someone who implements (occassionally) servers but not viewers,
I must say I'm a bit surprised (and very displeased) by this attitude
which seems to be prevalent... (if you think I'm being self-righteous,
please read on before making up your minds)

A lot of people don't want certain features -- not because they believe
thee features aren't useful or appropriate -- but because they are
worried about the complexity of implementing them.

Now while I'm all for pragmatism in programming, I think that
lobotomizing a specification just because the implementation *might*
be "challenging" is not just lazy, but extremely unhealthy.

So, I'm asking you collectively to think twice about your reasons
for wanting to kill certain features.  Is it *really* unnecessary,
or just too much hassle to implement?  And be honest about your
motivations for thinking which of the two it might be.

After a little thought, many of these problems are less daunting
that at first glance.  Don't Be Discouraged So Quickly.

> I would like to see the DTD augmented with some implementation
> notes, however.

This is a good idea.  I had to write some table layout software
myself about 2-1/2 years ago when HTML didn't handle such things
(it was in RTF, sigh) and there are clever ways to handle these
prbolems that aren't always obvious.  So, if you come up with
something "handy" or stumble on a fast and efficient algorithm,
please spread it around or suggest a pointer/tip to be included
in the implementation notes.

> It's easy enough to realize that you need to
> keep track of the maximum height of a row during the first formatting pass,
> what is not so obvious is that there is a trick you can use to avoid having
to
> do a second formatting pass. The trick is to keep track of which visual
> elements are formatted in each cell, and then go back and "fix" their
vertical
> position based on VALIGN after the entire row is formatted. Some words to
> that effect, as well as reiterating the need for a pre-pass on tables, would
> be helpful.

You could parse (recursively) left to right, keeping track of the maximum
height went pushing down cells, and then redistribute the maximum height
when popping the cells back off the stack (ie. returning, right-to-left).

-Philip