vertical size calculation

I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or anything
but tabular data, is a fox paw of major proportions.

So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone could
explain it to me without putting me in a technospeak coma. (just kidding --
any explanation will help.)

Larry

On 2008-07-21, Phonedude <fonedude (AT) verizon (DOT) net> wrote:

I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or anything
but tabular data, is a fox paw of major proportions.

So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone could
explain it to me without putting me in a technospeak coma. (just kidding --
any explanation will help.)

For most box types (like the ul) when you set the height you are setting
the height of the "content box", which is the bit _inside_ the padding
and borders.

Suppose you set a height of 100px and there is a 5px border top and
bottom. Then the height of the border box (i.e. measured from the top of
the top border to the bottom of the bottom border) will be 110px.

That's the CSS way and it works like that for everything except tables
(and some of the UI replaced elements-- buttons and so on-- which is a
different rat's nest we won't worry about here).

The reason tables are different involves a bit of a nasty wrinkle
between HTML and CSS. The HTML spec says that the width attribute on a
table sets the width of the entire table (i.e. including borders, which
is NOT the usual CSS way).

So (A):

<table width=100>

means you get a border box width of 100px (so the content box width will
be less if the table has left or right borders).

But then if you read the CSS 2.1 specification, it says that the CSS
width property sets the content box width (and it doesn't say it
doesn't apply to tables, which means it does).

So (B):

<table style="width: 100px">

ought strictly to mean you get a content box width of 100px (therefore a
border box width of >100px if the table has left or right borders).

But most implementors thought it was silly that the CSS equivalent (B)
should mean something different from what is in practice (if not
officially) the HTML version of the same thing (A). So for tables, in
practically all browsers, width: 100px means the same as width=100, i.e.
sets border box width, whether you do it the CSS way or the HTML way.

And then we come to height. According to HTML, tables don't have have a
height attribute, so <table height=100> is invalid. But many browsers
allow it anyway.

This leaves implementors with a further dilemma. On the one hand since
height=100 doesn't really exist in HTML there's no reason why height:
100px in CSS shouldn't set the content-box height like the CSS spec
says-- there's no HTML spec for height saying anything different. But on
the other hand most web authors can't chew gum and walk at the same
time. They don't read specifications and will be just be unpleasantly
surprised if width sets the border box but height sets the content box.

I'm fairly sure I've seen both approaches: in some versions of some
browsers height on a table sets content area height, in others it sets
border box height. I think what you're seeing is one in which it sets
border box height and that's why it's working differently from the ul.

All very annoying, but this is one of the reasons to avoid tables for
layout.

In article <g628qm$3un$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net>
wrote:

I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or anything
but tabular data, is a fox paw of major proportions.

OK, but as long as you understand what tabular data is. Your Officers is
tabular data. That does not mean the data has to be put into a table.
But it is table material if you want to use tables just for the
Officers. The Caption would be Officers, the left col would be their
position, the middle col their name and the third right col their phone
number. I mention this just to warn you not to be *too frightened" of
tables, I am not recommending how to proceed.

So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone could
explain it to me without putting me in a technospeak coma. (just kidding --
any explanation will help.)

What precisely is the question? How do you calculate table heights?
Mostly you don't at all and just let the content determine it. Your
three red bordered yellow boxes have different heights according to the
width of my browser. Nothing wrong with that. And what is this business
about lists? Where are you wanting to use a list? Your "LINKS" are a
good candidate to be listed. You *could* list the Officers I suppose,
though a table would be much the more appropriate (meaningful) thing.

--
dorayme

"dorayme" <doraymeRidThis (AT) optusnet (DOT) com.au> wrote

In article <g628qm$3un$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net
wrote:

I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or
anything
but tabular data, is a fox paw of major proportions.


OK, but as long as you understand what tabular data is. Your Officers is
tabular data. That does not mean the data has to be put into a table.
But it is table material if you want to use tables just for the
Officers. The Caption would be Officers, the left col would be their
position, the middle col their name and the third right col their phone
number. I mention this just to warn you not to be *too frightened" of
tables, I am not recommending how to proceed.


So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to
use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone
could
explain it to me without putting me in a technospeak coma. (just
kidding --
any explanation will help.)


What precisely is the question? How do you calculate table heights?
Mostly you don't at all and just let the content determine it. Your
three red bordered yellow boxes have different heights according to the
width of my browser. Nothing wrong with that. And what is this business
about lists? Where are you wanting to use a list? Your "LINKS" are a
good candidate to be listed. You *could* list the Officers I suppose,
though a table would be much the more appropriate (meaningful) thing.

The LINKS section is the first one where I replaced a table with a list
because, as you point out, the data are not tabular. The question, perhaps
poorly stated, is why are the heights of list boxes different from table
boxes when both are specified in an inbedded CSS style section. I do not
understand your statement about the three boxes being of different heights
according to the width of your browser. Two of the boxes are tables and
should be the exact same height as they use the same CSS style class. The
third box is a list and uses a style statement copied and pasted from the
table box statement, but I had to put a different em value in it to get the
same vertically sized box.

Larry
http://www.mclriverview.org

"Ben C" <spamspam (AT) spam (DOT) eggs> wrote

On 2008-07-21, Phonedude <fonedude (AT) verizon (DOT) net> wrote:
I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or
anything
but tabular data, is a fox paw of major proportions.

So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to
use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone
could
explain it to me without putting me in a technospeak coma. (just
kidding --
any explanation will help.)

For most box types (like the ul) when you set the height you are setting
the height of the "content box", which is the bit _inside_ the padding
and borders.

Suppose you set a height of 100px and there is a 5px border top and
bottom. Then the height of the border box (i.e. measured from the top of
the top border to the bottom of the bottom border) will be 110px.

That's the CSS way and it works like that for everything except tables
(and some of the UI replaced elements-- buttons and so on-- which is a
different rat's nest we won't worry about here).

The reason tables are different involves a bit of a nasty wrinkle
between HTML and CSS. The HTML spec says that the width attribute on a
table sets the width of the entire table (i.e. including borders, which
is NOT the usual CSS way).

So (A):

table width=100

means you get a border box width of 100px (so the content box width will
be less if the table has left or right borders).

But then if you read the CSS 2.1 specification, it says that the CSS
width property sets the content box width (and it doesn't say it
doesn't apply to tables, which means it does).

So (B):

table style="width: 100px"

ought strictly to mean you get a content box width of 100px (therefore a
border box width of >100px if the table has left or right borders).

But most implementors thought it was silly that the CSS equivalent (B)
should mean something different from what is in practice (if not
officially) the HTML version of the same thing (A). So for tables, in
practically all browsers, width: 100px means the same as width=100, i.e.
sets border box width, whether you do it the CSS way or the HTML way.

And then we come to height. According to HTML, tables don't have have a
height attribute, so <table height=100> is invalid. But many browsers
allow it anyway.

This leaves implementors with a further dilemma. On the one hand since
height=100 doesn't really exist in HTML there's no reason why height:
100px in CSS shouldn't set the content-box height like the CSS spec
says-- there's no HTML spec for height saying anything different. But on
the other hand most web authors can't chew gum and walk at the same
time. They don't read specifications and will be just be unpleasantly
surprised if width sets the border box but height sets the content box.

I'm fairly sure I've seen both approaches: in some versions of some
browsers height on a table sets content area height, in others it sets
border box height. I think what you're seeing is one in which it sets
border box height and that's why it's working differently from the ul.

All very annoying, but this is one of the reasons to avoid tables for
layout.

I get that and your explanation sort of makes sense to me. I think you said
that the CSS box height spec should produce boxes of the same height, but
that browsers interpret them differently. What I did was copy the CSS for
the table box and paste it in as a new CSS for the list box. When the result
was boxes of different height boxes which confused me. I experimented a
little and produced an acceptable result, but it didn't work the way I
expected. Live an learn.

Thanks for the reply and the explanation.

Larry

In article <g639pm$vrr$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net>
wrote:

"dorayme" <doraymeRidThis (AT) optusnet (DOT) com.au> wrote in message
news:doraymeRidThis-59DF3D.08415122072008 (AT) news-vip (DOT) optusnet.com.au...
In article <g628qm$3un$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net
wrote:

I am starting to get a little more serious about my html and according to
the collective wisdom of the universe using tables for layout, or
anything
but tabular data, is a fox paw of major proportions.


OK, but as long as you understand what tabular data is. Your Officers is
tabular data. That does not mean the data has to be put into a table.
But it is table material if you want to use tables just for the
Officers. The Caption would be Officers, the left col would be their
position, the middle col their name and the third right col their phone
number. I mention this just to warn you not to be *too frightened" of
tables, I am not recommending how to proceed.


So I started converting my volunteer website http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to
use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone
could
explain it to me without putting me in a technospeak coma. (just
kidding --
any explanation will help.)


What precisely is the question? How do you calculate table heights?
Mostly you don't at all and just let the content determine it. Your
three red bordered yellow boxes have different heights according to the
width of my browser. Nothing wrong with that. And what is this business
about lists? Where are you wanting to use a list? Your "LINKS" are a
good candidate to be listed. You *could* list the Officers I suppose,
though a table would be much the more appropriate (meaningful) thing.

The LINKS section is the first one where I replaced a table with a list
because, as you point out, the data are not tabular.

Well, I did not quite say the links were *not tabular*. Most people
would say they were not tabular in nature. I happen to think they are
but that a list would still be more appropriate here. It is a
complicated issue and I won't bother you with it. You are right to put a
list of links in an unordered HTML list.

The question, perhaps
poorly stated, is why are the heights of list boxes different from table
boxes when both are specified in an inbedded CSS style section.

Ben has given some explanation of this since. I have simply come to
expect that you have to work too hard to get different elements to be
the same height and not to bother. But your design aims might be
stricter than mine.

I do not
understand your statement about the three boxes being of different heights
according to the width of your browser.

Perhaps I better post you some screen shots then? Just a minute.

<http://dorayme.890m.com/alt/justPics/marinecorps_narrow.png>

<http://dorayme.890m.com/alt/justPics/marinecorps_wider.png>

(Don't worry about the colours, it's to save bandwidth, I actually saw
them as bright as you intended <g>)

Two of the boxes are tables and
should be the exact same height as they use the same CSS style class. The
third box is a list and uses a style statement copied and pasted from the
table box statement, but I had to put a different em value in it to get the
same vertically sized box.

The situation is a little confused because the list is in a table cell
is it not?

I would suggest you take the tutes at

<http://htmldog.com/guides/htmlbeginner/>

and learn to separate style from content. You will soon see why it is
not a good idea to be doing stuff like using heading tags to make text
bold. I advise to first get used to *not worrying about heights* until
you are more comfortable about laying out a page with simple meaningful
mark up and simple css. Getting elements to be the same height is a
harder game. I point out, again, even with tables, this is not always so
simple.

Larry
http://www.mclriverview.org

--
dorayme

On 2008-07-22, Phonedude <fonedude (AT) verizon (DOT) net> wrote:
[...]

I get that and your explanation sort of makes sense to me. I think
you said that the CSS box height spec should produce boxes of the same
height, but that browsers interpret them differently.

Basically height sets the content-box height (so the height not counting
padding or borders) for everything except tables.

For tables, in some browsers, it sets the border-box height (so counting
padding and borders). The reasons why were suggested in the previous
post.

What I did was copy the CSS for the table box and paste it in as a new
CSS for the list box. When the result was boxes of different height
boxes which confused me. I experimented a little and produced an
acceptable result, but it didn't work the way I expected.

The difference between the height you used for the ul and height you
used for the table is the same as the total top/bottom border you've
got.

Problem is the border is in px and the height in em, so 22.1em or
whatever you had isn't going to work quite right at all font sizes.

"Ben C" <spamspam (AT) spam (DOT) eggs> wrote

On 2008-07-22, Phonedude <fonedude (AT) verizon (DOT) net> wrote:
[...]
I get that and your explanation sort of makes sense to me. I think
you said that the CSS box height spec should produce boxes of the same
height, but that browsers interpret them differently.

Basically height sets the content-box height (so the height not counting
padding or borders) for everything except tables.

For tables, in some browsers, it sets the border-box height (so counting
padding and borders). The reasons why were suggested in the previous
post.

What I did was copy the CSS for the table box and paste it in as a new
CSS for the list box. When the result was boxes of different height
boxes which confused me. I experimented a little and produced an
acceptable result, but it didn't work the way I expected.

The difference between the height you used for the ul and height you
used for the table is the same as the total top/bottom border you've
got.

Problem is the border is in px and the height in em, so 22.1em or
whatever you had isn't going to work quite right at all font sizes.

Thanks again. Between you and Dorayme I think I am beginning to understand
that things don't work the way they oughtta. Silly me.

Larry

"dorayme" <doraymeRidThis (AT) optusnet (DOT) com.au> wrote

In article <g639pm$vrr$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net
wrote:

"dorayme" <doraymeRidThis (AT) optusnet (DOT) com.au> wrote in message
news:doraymeRidThis-59DF3D.08415122072008 (AT) news-vip (DOT) optusnet.com.au...
In article <g628qm$3un$1 (AT) aioe (DOT) org>, "Phonedude" <fonedude (AT) verizon (DOT) net
wrote:

I am starting to get a little more serious about my html and according
to
the collective wisdom of the universe using tables for layout, or
anything
but tabular data, is a fox paw of major proportions.


OK, but as long as you understand what tabular data is. Your Officers
is
tabular data. That does not mean the data has to be put into a table.
But it is table material if you want to use tables just for the
Officers. The Caption would be Officers, the left col would be their
position, the middle col their name and the third right col their phone
number. I mention this just to warn you not to be *too frightened" of
tables, I am not recommending how to proceed.


So I started converting my volunteer website
http://www.mclriverview.org
from tables to lists and immediately found that the list box height is
apparently calcuated differently from the table box height. I have to
use a
slight smaller em value to make my list the same size as the table it
replaces. I don't understand this and would appreciate it if someone
could
explain it to me without putting me in a technospeak coma. (just
kidding --
any explanation will help.)


What precisely is the question? How do you calculate table heights?
Mostly you don't at all and just let the content determine it. Your
three red bordered yellow boxes have different heights according to the
width of my browser. Nothing wrong with that. And what is this business
about lists? Where are you wanting to use a list? Your "LINKS" are a
good candidate to be listed. You *could* list the Officers I suppose,
though a table would be much the more appropriate (meaningful) thing.

The LINKS section is the first one where I replaced a table with a list
because, as you point out, the data are not tabular.

Well, I did not quite say the links were *not tabular*. Most people
would say they were not tabular in nature. I happen to think they are
but that a list would still be more appropriate here. It is a
complicated issue and I won't bother you with it. You are right to put a
list of links in an unordered HTML list.

The question, perhaps
poorly stated, is why are the heights of list boxes different from table
boxes when both are specified in an inbedded CSS style section.

Ben has given some explanation of this since. I have simply come to
expect that you have to work too hard to get different elements to be
the same height and not to bother. But your design aims might be
stricter than mine.

I do not
understand your statement about the three boxes being of different
heights
according to the width of your browser.

Perhaps I better post you some screen shots then? Just a minute.

http://dorayme.890m.com/alt/justPics/marinecorps_narrow.png

http://dorayme.890m.com/alt/justPics/marinecorps_wider.png

(Don't worry about the colours, it's to save bandwidth, I actually saw
them as bright as you intended <g>)


Two of the boxes are tables and
should be the exact same height as they use the same CSS style class.
The
third box is a list and uses a style statement copied and pasted from the
table box statement, but I had to put a different em value in it to get
the
same vertically sized box.

The situation is a little confused because the list is in a table cell
is it not?

I would suggest you take the tutes at

http://htmldog.com/guides/htmlbeginner/

and learn to separate style from content. You will soon see why it is
not a good idea to be doing stuff like using heading tags to make text
bold. I advise to first get used to *not worrying about heights* until
you are more comfortable about laying out a page with simple meaningful
mark up and simple css. Getting elements to be the same height is a
harder game. I point out, again, even with tables, this is not always so
simple.

Larry
http://www.mclriverview.org

--
dorayme

Thanks for the pictures -- they explained it nicely. The narrower width
squeezed the contents so they no longer fit in the suggested box height so
the box stretched to hold them. I only checked it at two different
resolutions, and it seemed ok -- as I said before, live and learn.

Larry