# Table problem

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on

I have a table (1) with 3 tables in it, (a, b and c).

There are several rows in table a
There are 2 rows in table b and table c is just a "td" and not an actual
table - it is used as a narrow border

According to the ammount of text written in table "a" the height of "a"
According to the ammount of text written in table "b" the height of "b"

I want to adjust the height of table "a" dynamicaly to match the height
of table "b" (when table "b" is higher).
AND/OR
I want to adjust the height of table "b" dynamicaly to match the height
of table "a" (when table "a" is higher).

How do I do this?

A visual version of the problem..

http://www.vasatrampet.se/whythis2.html

Garry Jones
Sweden

## Re: Table problem

actual

The bigger question is, why does that warrant having two nested tables in
it?

Ideally, you'd use CSS for layout, but that's obviously going to be
beyond your skillset. There's no need to use two nested tables here. Take
those nested tables out.

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

Ouch! <g>

OP:

The left column, with the pictures in it, should be just that -- a
column (td) not a table.  It is putting it into a column that will
give you the same-height characteristic.

At least this is what it looks like to me, but the code "view source"
showed me is too confusing to really get my arms around and I don't
have the time (or more importantly, the inclination) to clean it up.

The next time you post a table example I would suggest the following
to help those who would help you: use "border" in every table, and
give a different unique easily-recognized color to everything you can
(stick to primaries if possible, FF0000 is easily recognized as red),
in order to make it easier to relate the code to the cells.  In fact
the exercise of doing that will probably make the difficulty blatantly
clear to you and you won't need to ask.

--
http://www.ren-prod-inc.com/hug_soft/store.php?action=contact

## Re: Table problem

I wasn't trying to be a dick. I was just saying that if the OP can't
figure out how to nest some tables two-deep, that CSS is just out of the
question.

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

Effective use of CSS requires a stronger knowledge of HTML than most
newbies have.

Newbies approach HTML as if it was a language for visual presentation.
Before they can begin using CSS, they need to abandon that line of thinking
and come to the understanding that HTML is simply a language for defining
the structure of the content (<h1> is a heading, <p> is a paragraph, and
all that). So long as they think a table is something to position things,
that's all they'll be able to handle.

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

I agree for the most part -- html is certainly an information
structure definition language, and CSS (from the *very* little I know
about it so far) is the associated presentation language, which is all
well and good and as it seems it should be.

The only thing I partially disagree with is the implications of your
statement about tables being to position things.  If you step back a
bit and look at a table, its entire function in life is to position
things (eg, tabular data).  There are real and valid uses for tables,
which (presumably) beyond newbiness one recognizes.  I assume you
didn't mean "tables have no place in positioning things" and that you
meant "tables are not the proper tool for layout" instead.

I'll freely admit that I still have html that uses an inline table for
the sole purpose of indenting text; mea culpa, but it'll stay that way
for now because I've not yet gotten to really digging into CSS, and
even once I learn CSS... well, as a programmer I have a longstanding
belief (validated by the renowned Murphy) that working code (however
ugly) should never be modified without good reason. <g>

I'm still chewing on how just extensively I'll buy into CSS, for
reasons of browser compatability; I have yet to run into a browser
that fails to render properly coded tables correctly, even when they
are obscenely nested.  But that's a nudder issue, and if I can stall
it long enough the browser compatabilities will fall by the wayside.

--
http://www.ren-prod-inc.com/hug_soft/store.php?action=contact

## Re: Table problem

Tables, as you've said, are for tabular data.
I think of it this way - if I wouldn't put it in a CSV, I wouldn't put it
in an HTML table.

Hence the reason why I still have some tables-based sites in my
portfolio.

I've seen nested tables actually crash a browser. Get about 8-deep and
play with some legacy browsers.

I once did a site fix of a web site that crashed Netscape before the page
even loaded. It had a menu which was 8 deep just for a list of links.  By
the time I was done with the site, it looked the same (which wasn't
saying much, really), was only 7kb for the markup (as opposed to more
than 100kb thanks to the gratuitous graphics, javascript, and nested
tables) and worked in everything from NN4.x+ and IE4+

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

Fleeing from the madness of the . jungle
and said:

Whilst agreeing vehemently with the principle of 'help me to help you'
.... perhaps the reviewer could simply use the IE[1]/Dev Toolbar /outline
tool to achieve a similar result without coding.

[1] yes, yes I'm sure, well almost positive, that other UAs have similar
functionality - I just happened to have that one open.
--
William Tasso

whither a trophy?

## Re: Table problem

<sarcasm>
I am a battered child of the computer era.  I have learned that the
iron is always hot, and the install program will always grasp your
balls with a grip of steel and never let go until you get pissed and
zero the hard-drive at the sector level.  I am using ancient browsers
because they haven't squeezed hard enough yet to initiate the
wipe-drive procedure, and I don't think they have such modern goodies.
There is a refrigerator on my front porch, an old engine block nearby,
and a gutted BMW convertible planter in the front yard.  I have
written operating system kernel components, I have developed secure
client-server programs (and been forced by the evil NSA to license an
encryption algorithm for export), and I have read enough internet
RFC's to become totally and completely paranoid (in addition to being
amazed by how crude something can be and still work).  I recently
reclaimed significant processor resources on my wife's machine by the
simple expedient of removing a particular browser toolbar, my machine
is slow enough already, and I do not have time to institute the
wipe-drive procedure this week in the highly-probably case that the
install program should be not-nice to me.  I'll continue to write the
1's and 0's on paper and enter them through the toggle switches until
they pry the pencil out of my cold dead hands, thank you.
</sarcasm>

--
http://www.ren-prod-inc.com/hug_soft/store.php?action=contact

## Re: Table problem

And lo, Garry Jones didst speak in alt.www.webmaster:

Should be obvious...

Grey

## Re: Table problem

[Note to self:  Pocket the phrase "should be obvious" for later use in
cases where the source is obfuscated beyond readability and I have no
clue what the problem might be.]

<g>

--
http://www.ren-prod-inc.com/hug_soft/store.php?action=contact

## Re: Table problem

And lo, hug didst speak in alt.www.webmaster:

Have you ever heard the one about the guy who went to his doctor and said:
"Hey, Doc, it hurts when I go like this..."

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#sear - Orca Search: Full-featured spider
and site-search engine

## Re: Table problem

Doctor:  Do you hear voices?
Patient:  WHAT?

--
http://www.ren-prod-inc.com/hug_soft/store.php?action=contact

## Re: Table problem

posted something that included:

You can't. The height of column B depends on the font in which it is
rendered - and if the font you specify isn't present, the browser
feels free to grab any ole font it wants to use. That means no matter
how many CPU cycles you throw at the problem, you cannot determine how
high column B is.

<digression>
One of the problems with websites is that text lines are too long. For
optimum ease of reading, a column of text ought to be about 39
characters wide. CNN.com runs over 60 characters and MSNBC runs about
48 characters, and they are among the best and brightest; it's not
hard to find sites that have text which is considerably more difficult

Newspapers and magazines solve the problem by publishing their text in
multiple columns - but Netscape/3's MULTICOL tag didn't work right,
and nobody has ever introduced one that worked right.
</digression>

Back to your problem. Instead of making the columns separate tables,
make them TDs of the same table, and they will be the same height. You
could use a bgcolor in column 1 to color it yellow, and use a valign
attribute to bring the contents to the top of the column.

Good luck in arriving at something which is acceptable to you.

--
AmishHosting.com

## Re: Table problem

Do you have a source for this claim?
I don't mean some conjecture-laden BS, but an actual usability study which
measured effectiveness and efficiency?

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

On Wed, 01 Mar 2006 12:49:54 -0600, Karl Groves put finger to keyboard
and typed:

I don't know if there's anything specifically relating to websites,
but the relationship between line length and readability is well
understood in offline (print) contexts. So there is good backing for a
claim that many websites have excessively long lines, although I'm
less sure that around 39 characters is the optimum.

Mark
--
Visit: http://www.MotorwayServices.info - read and share comments and opinons
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!

## Re: Table problem

On Wed, 01 Mar 2006 20:31:51 +0000, Mark Goodge wrote:

I'd say 39 is a bit too little. Of course it depends on the font size.

## Re: Table problem

There is a fair amount of research online that discusses this. I doubt Paul
has seen it, considering that he's dead wrong.

--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

## Re: Table problem

Wouldn't it depend on how wide the characters are? i would think that the
width of the line in centimetres was more important than the number of
characters. Like in a news paper where columns are narrow.

GD

## Re: Table problem

On Wed, 01 Mar 2006 21:06:37 GMT, Gemma Davies put finger to keyboard
and typed:

In print, it's related primarily to physical width of the line and the
reader's distance from the page. Given a typical reading distance,
this means that the font size is determined more by the line length
than the other way around. It's not a coincidence that most books,
newspapers and magazines all have near enough the same font size for
primary content. Obviously, with a proportionally spaced font, there
isn't a fixed number of characters per line.

To go into this in a little more detail: A person's primary focus when
reading is quite narrow - no more than a word or two. But, with normal
peripheral vision, they can also see quite a lot either side of what's
actually being read. So you have a situation a bit like this:

|<---------------- what I can see ------------------>|
|<- what I am ->|
line of text line of text line of text line of text line of text

As someone reads, their eyes scan from side to side on the page,
following the words from left to right (or right to left, in some
languages) and then returning to the start of the next ine when the
end of the current line is reached. Text that is too narrow is
uncomfortable to read, because it requires a lot back-and-forth
movement to take in - longer lines can be read with a longer
continuous scan before needing to put in a visual carriage return. But
if the line is too long, then the start of the line begins to approach
the limit of the reader's peripheral vision, which causes an entirely
different problem as the eye loses the visual "anchor" to the location
that it needs to return to when the line is complete.

So the optimum line length is one which is as long as possible within
the limits of the reader's good peripheral vision - as long as
possible, to make reading smooth rather than jerky, but not so long
that the anchor is lost. Using my diagram from previously, it means
something like this:

|<-------------- what I can see-----
|               |<- what I am ->|
|               |    reading    |
|       start of line wibble end
|       start of line wibble end
|       start of line wibble end

This example is too short, because the peripheral vision has plenty of
"spare" space to the left of the start of the line when the end of the
line is reached. The eye is having to shuttle back and forth often,
and the ability to read a longer line in one smooth movement isn't
being used.

|<-------------- what I can see-----
|                |<- what I am ->|
|                |    reading    |
start| of line wibble flirble blah end
start| of line wibble flirble blah end

This is too long - the reader's peripheral vision is losing the start
of the line when the eye reaches the end.

|<-------------- what I can see-----
|                |<- what I am ->|
|                |    reading    |
| start of line flirble wibble end
| start of line flirble wibble end

And this one is the optimum - the line goes as far as it can, while
still remaining within the field of vision.

(Before anyone points it out, these diagrams are not in any way to
scale!)

What tends to happen, if a line is too long, is that the reader will
automatically tend to increase the reading distance until the whole of
the line falls within the limits of peripheral vision. But that makes
the text harder to read, as the font is smaller when seen from a
distance. And, of course, people with poorer eyesight often have to
move in closer in order to see the text, meaning that the line ends
move outside their peripheral vision. On the other hand, if a line is
too short, then the eye doesn't get to use all of its peripheral
vision and has to engage in excessive "carriage return" movements.

However, the two failures are not identical. Text that is a bit too
short isn't a major problem, as it only increases the newline
movements by a small amount - it has to be a lot less than the optimum
before it will be noticeably uncomfortable to read. But text that is
too long becomes very difficult to read even if it's only a short
distance outside the reader's peripheral vision - once the anchor is
lost, it's lost, and it only takes a short excess length to lose it.
So the practical optimum, when designing for a mixed audience, is
shorter than the actual optimum for a typical normally-sighted adult;
someone with normal eyesight can adapt to shorter-than-ideal lines
more easily than someone with poor eyesight can adapt to longer lines.

The real life optimum, therefore, is actually at the other end of the
scale - the ideal length is one that is just long enough to avoid
normally-sighted readers thinking "these lines are too short", thus
giving the maximum possible leeway for readers with poorer eyesight. I
suspect that this principle may be behind the theory that the optimum
line length on screen is around 39 characters, as that would be long
enough to avoid excessive discomfort to normally-sighted readers while
being short enough to accomodate as many weaker eyes as possible. But
I'm not aware of any hard evidence to support this figure; it sounds
more like a conjecture (albeit a fairly rational one) to me.

Mark
--
Visit: http://www.ukcommunityradio.info - Community Radio in the UK
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!