By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,763 Members | 1,641 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,763 IT Pros & Developers. It's quick & easy.

Table width error???

P: n/a

Am I misunderstanding the CSS specifications or is Firefox (version 1.0.6)
(and Opera) doing the wrong thing?

It appears that Firefox 1.0.6 includes the border in width calculations
for tables but not in height calculations.

Oh, and Opera version 8.02 does the same thing.

|<-->| |<-->| <------ border
|<------------>| <------ table contents
|<---------------------->| <------ width as rendered by Firefox
(*includes* border)
(it should be the width of the
contents, shouldn't it?)
+------------------------+ -----
| | <--- border
| +--------------+ | -----
| | | | ^
| | | | | <--- contents and height
| | | | v (height excludes border)
| +--------------+ | -----
| | <--- border
+------------------------+ -----
I can get a table I want to render correctly without specifying a height
and width but, in that case, the table's border is initially too small and
then redrawn with an ever-increasing size as rows are read from the HTML
and only reaches the correct size when the table is entirely read. (The
actual table is *much* larger than the example one, 32 rows and columns
with the height and width dynamically adjusted with JavaScript so only
some (9 rows and 9 columns) are visible at any given time.) I wanted to
specify the size of the visible part of the table at the start so the
border could immediately be drawn at the right size.

A portion of the HTML for an example 6-column, 2-row table with images:

....
....
<h2>No height and width specified</h2>
<table style="border:32px ridge #50C040;font-size: 0px; padding: 0" cellspacing="1">
....
....
<h2>Height = 127px; width = 431px</h2>
<h3>(Height = 2 * image height + 1; Width = 6 * image width + 5)</h3>
<p>The table should be the same as above -- but isn't.</p>
<table style="border:32px ridge #50C040;font-size: 0px; padding: 0; height: 127px; width: 431px" cellspacing="1">
....
....
<h2>Height = 127px; width = 495px</h2>
<h3>(Height = 2 * image height + 1; Width = 6 * image width + 5 + 64)</h3>
<p>Adding twice the width of the border to the width seems to correct the size problem
but the border size should not have had any influence on the size of the content area
of the table.</p>
<table style="border:32px ridge #50C040;font-size: 0px; padding: 0; height: 127px; width: 495px" cellspacing="1">
....
....
However, Firefox's treatment of a width specifier (but not the height
specifier) seems to counter-intuitively include the border. The complete
example file (6KB):
http://www.chebucto.ns.ca/~af380/Tab...idthError.html

The first table lacks height and width for the overall table style,
the second has the width I *thought* I should use and gets rendered too
small and the third table gets rendered the size I want but I don't
think Firefox or Opera are really doing the right thing.

So, am I wrong or are both Firefox and Opera wrong?

--
``Why don't you find a more appropiate newsgroup to post this tripe into?
This is a meeting place for a totally differnt kind of "vision impairment".
Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
off-topic religious/political post, March 28, 2005
Sep 16 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
It appears that Firefox 1.0.6 includes the border in width calculations
for tables but not in height calculations.


Tables don't need specified heights, ever. Stop abusing tables.

--
Spartanicus
Sep 16 '05 #2

P: n/a

On Fri, 16 Sep 2005, Spartanicus wrote:
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
It appears that Firefox 1.0.6 includes the border in width calculations
for tables but not in height calculations.


Tables don't need specified heights, ever. Stop abusing tables.


Why is it misuse? The CSS specs appear to support it:

[snip]
: 17.5.3 Table height algorithms
:
: The height of a table is given by the 'height' property for the 'table'
: or 'inline-table' element. A value of 'auto' means that the height is
: the sum of the row heights plus any cell spacing or borders. Any other
: value specifies the height explicitly; the table may thus be taller or
: shorter than the height of its rows. The 'height' property on 'table'
: boxes is treated as a minimum height. CSS 2.1 does not define how extra
: space is distributed when the 'height' property causes the table to be
: taller than it otherwise would be. Note. Future versions of CSS may
: specify this further.
[snip]

If the height and width are specified for the table, the border can be
displayed immediately with the correct size. If there is no specification
for the height and width, Firefox initially displays the wrong size (too
small) border and then slowly enlarges the table border as more of the
rows are read. That is the reason I wanted to specify the size -- so the
border would appear the correct size immediately. There is no problem of
varying text sizes as the table will be using only fixed-sized images.
How can this be "abuse"?

(You don't *really* have to specify the size of images on a web page
either (if you're not having the browser display them in other than their
correct size) since the browser can eventually determine image size when
an image is loaded but a page with lots of images is going to be
rearranged multiple times with stuff hopping all over the place as more
and more images are fetched if you don't specify the image sizes in your
HTML.)

HOWEVER, my question was about the *width* appearing to be miscalculated.

Am I right that Firefox and Opera miscalculate the width by including the
border *within* the table area whose width is specified or am I wrong?
And why is the border included within the specified width when it isn't
included within the specified height?

--
``Why don't you find a more appropiate newsgroup to post this tripe into?
This is a meeting place for a totally differnt kind of "vision impairment".
Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
off-topic religious/political post, March 28, 2005

Sep 16 '05 #3

P: n/a
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
>It appears that Firefox 1.0.6 includes the border in width calculations
>for tables but not in height calculations.
Tables don't need specified heights, ever. Stop abusing tables.


Why is it misuse?


Tables are for marking up tabular data, the content should be allowed to
expand the container (text zooming etc.)
The CSS specs appear to support it:
CSS "supports" all sorts of inappropriate use, that doesn't justify
doing so.
If the height and width are specified for the table, the border can be
displayed immediately with the correct size.
Not relevant, borders aren't content. The page might be laid out
slightly more quickly, but at the expense of much more important
functionality.
If there is no specification
for the height and width, Firefox initially displays the wrong size (too
small) border and then slowly enlarges the table border as more of the
rows are read.
URL? Set "empty-cells" set to "show"?
That is the reason I wanted to specify the size -- so the
border would appear the correct size immediately. There is no problem of
varying text sizes as the table will be using only fixed-sized images.
How can this be "abuse"?
Are these images tabular data?

User has image display disabled, alt text shows, your fixed width/height
table is hogging the screen space.
(You don't *really* have to specify the size of images on a web page
either (if you're not having the browser display them in other than their
correct size) since the browser can eventually determine image size when
an image is loaded but a page with lots of images is going to be
rearranged multiple times with stuff hopping all over the place as more
and more images are fetched if you don't specify the image sizes in your
HTML.)
The screen space occupied by an image's box when the alt content is
showing collapses.
HOWEVER, my question was about the *width* appearing to be miscalculated.

Am I right that Firefox and Opera miscalculate the width by including the
border *within* the table area whose width is specified or am I wrong?


Default table "borders" consist of two parts, a border around the table,
and a border around cells. Unless "empty-cells" is set to "show", a
browser may activate the cell borders incrementally as the images roll
in.

--
Spartanicus
Sep 16 '05 #4

P: n/a
Once upon a time *Norman L. DeForest* wrote:

HOWEVER, my question was about the *width* appearing to be miscalculated.


Why do you think it's miscalculated? Because IE says different? Then
stop using a broken non standard old browser as referent!

--
/Arne
Now killing all posts originating at GoogleGroups
Workaround: http://www.safalra.com/special/googlegroupsreply/
Sep 16 '05 #5

P: n/a

On Fri, 16 Sep 2005, Spartanicus wrote:
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
>It appears that Firefox 1.0.6 includes the border in width calculations
>for tables but not in height calculations.

Tables don't need specified heights, ever. Stop abusing tables.
Why is it misuse?


Tables are for marking up tabular data, the content should be allowed to
expand the container (text zooming etc.)


And if the size of the content is known beforehand and *fixed* in size
with no text?
The CSS specs appear to support it:
CSS "supports" all sorts of inappropriate use, that doesn't justify
doing so.
If the height and width are specified for the table, the border can be
displayed immediately with the correct size.


Not relevant, borders aren't content. The page might be laid out
slightly more quickly, but at the expense of much more important
functionality.
If there is no specification
for the height and width, Firefox initially displays the wrong size (too
small) border and then slowly enlarges the table border as more of the
rows are read.


URL? Set "empty-cells" set to "show"?
That is the reason I wanted to specify the size -- so the
border would appear the correct size immediately. There is no problem of
varying text sizes as the table will be using only fixed-sized images.
How can this be "abuse"?


Are these images tabular data?


YES. It's a matrix of background images over which some cells will have
overlaying foreground images with transparent backgrounds, changing
dynamically using JavaScript.

User has image display disabled, alt text shows, your fixed width/height
table is hogging the screen space.
Then the user *can't* use the page. There is no alt text for background
images and none will be appropriate for foreground images. It's for a
*graphical* game. If you can't view images then you can't play the game.
(You don't *really* have to specify the size of images on a web page
either (if you're not having the browser display them in other than their
correct size) since the browser can eventually determine image size when
an image is loaded but a page with lots of images is going to be
rearranged multiple times with stuff hopping all over the place as more
and more images are fetched if you don't specify the image sizes in your
HTML.)


The screen space occupied by an image's box when the alt content is
showing collapses.
HOWEVER, my question was about the *width* appearing to be miscalculated.

Am I right that Firefox and Opera miscalculate the width by including the
border *within* the table area whose width is specified or am I wrong?


Default table "borders" consist of two parts, a border around the table,
and a border around cells. Unless "empty-cells" is set to "show", a
browser may activate the cell borders incrementally as the images roll
in.


The cells have no border. I was asking about the border around the table.
I thought that setting the outer table border to 16px to exaggerate the
effect in my example would illustrate what I was asking about.

Is the *outer* border of the table supposed to be included within the
specified height or not?

Please check one: ( ) Yes. ( ) No.

Is the *outer* border of the table supposed to be included within the
specified width or not?

Please check one: ( ) Yes. ( ) No.

Firefox and Opera apparently do *not* include the top and bottom borders
within the specified height but *do* include the left and right borders
within the specified width.

--
``Why don't you find a more appropiate newsgroup to post this tripe into?
This is a meeting place for a totally differnt kind of "vision impairment".
Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
off-topic religious/political post, March 28, 2005

Sep 16 '05 #6

P: n/a

On Fri, 16 Sep 2005, Arne wrote:
Once upon a time *Norman L. DeForest* wrote:

HOWEVER, my question was about the *width* appearing to be miscalculated.


Why do you think it's miscalculated? Because IE says different? Then
stop using a broken non standard old browser as referent!


No, I ignore IE except for fetching Windows updates or checking to see how
broken it is in comparison with other stuff. I'm not even considering
supporting it. (If IE happens to work, fine. If it doesn't, then the
IE users can just switch to Firefox or Opera or go play some other game.)

Firefox and Opera both put the outer top and bottom borders *outside* and
specified height. Both put the outer left and right borders *inside* the
specified width and crowd the content unless you add the twice the outer
border thickness to the width. It would seem to me that one of the two is
wrong or there is a major inconsistancy here.

If this inconsistancy *is* a bug in both Firefox and Opera then I would
like to report it as a bug. If it isn't a bug, then I would I would like
a straight answer that it isn't and a pointer to a reference that tells me
why it isn't -- not a pile of accusations that I shouldn't be doing this
or that or the other thing. Please! Check one:
( ) Yes it's a bug.
( ) No, it isn't a bug. Here's a reference: http://________________
( ) I don't know.

--
``Why don't you find a more appropiate newsgroup to post this tripe into?
This is a meeting place for a totally differnt kind of "vision impairment".
Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
off-topic religious/political post, March 28, 2005

Sep 16 '05 #7

P: n/a
Once upon a time *Norman L. DeForest* wrote:
On Fri, 16 Sep 2005, Arne wrote:
Once upon a time *Norman L. DeForest* wrote:
>
> HOWEVER, my question was about the *width* appearing to be miscalculated.
Why do you think it's miscalculated? Because IE says different? Then
stop using a broken non standard old browser as referent!


No, I ignore IE except for fetching Windows updates or checking to see how
broken it is in comparison with other stuff. I'm not even considering
supporting it. (If IE happens to work, fine. If it doesn't, then the
IE users can just switch to Firefox or Opera or go play some other game.)


Fine then.
Firefox and Opera both put the outer top and bottom borders *outside* and
specified height. Both put the outer left and right borders *inside* the
specified width and crowd the content unless you add the twice the outer
border thickness to the width. It would seem to me that one of the two is
wrong or there is a major inconsistancy here.


Well, try this then:
Putting the borders outside the width of the table should mean that
you can't set a table to 100% of the browser window, since the borders
(when they are added) would cause a horizontal scroll since the table
with border gets wider than 100% in reality. For the height there is
no problem since 99% of the time there is a vertical scrolling anyway.

--
/Arne
Now killing all posts originating at GoogleGroups
Workaround: http://www.safalra.com/special/googlegroupsreply/
Sep 16 '05 #8

P: n/a
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
>> Tables don't need specified heights, ever. Stop abusing tables.
>
>Why is it misuse?
Tables are for marking up tabular data, the content should be allowed to
expand the container (text zooming etc.)


And if the size of the content is known beforehand and *fixed* in size
with no text?


Images without alt content are decorative, not data, tabular or
otherwise, tables are for marking up data/content, ergo you are abusing
table markup.
Are these images tabular data?


YES. It's a matrix of background images over which some cells will have
overlaying foreground images with transparent backgrounds, changing
dynamically using JavaScript.


Images, CSS and javascript should be optional, if they are not then your
page is broken.
User has image display disabled, alt text shows, your fixed width/height
table is hogging the screen space.


Then the user *can't* use the page.


Can't, or your coding doesn't allow them to?
There is no alt text for background images
Again: CSS should be optional, background images are for decoration,
hence they don't need alt content.
and none will be appropriate for foreground images.
Using transparent foreground images is a hack.
It's for a
*graphical* game. If you can't view images then you can't play the game.


Can't, or your coding doesn't allow them to? If graphics are essential
then the page should relay that to people who do not display images.

--
Spartanicus
Sep 16 '05 #9

P: n/a

On Fri, 16 Sep 2005, Spartanicus wrote:
"Norman L. DeForest" <af***@chebucto.ns.ca> wrote:
>> Tables don't need specified heights, ever. Stop abusing tables.
>
>Why is it misuse?

Tables are for marking up tabular data, the content should be allowed to
expand the container (text zooming etc.)
And if the size of the content is known beforehand and *fixed* in size
with no text?


Images without alt content are decorative, not data, tabular or
otherwise, tables are for marking up data/content, ergo you are abusing
table markup.


My alternative would to use absolute positioning (and hiding and unhiding)
for several thousand images. I wouldn't have the disk space quota
available for that and nobody would want to have their browser take a
quarter of an hour to load the page.
Are these images tabular data?
YES. It's a matrix of background images over which some cells will have
overlaying foreground images with transparent backgrounds, changing
dynamically using JavaScript.


Images, CSS and javascript should be optional, if they are not then your
page is broken.


Face it. There are some things that rely on something other than plain
HTML and CSS. My browser of choice is Lynx. However, there are some
things that Lynx just can't do. The game I'm working on is one of them.
I either use JavaScript or I don't create the game.

The sliding-block puzzle referenced in my sig is another example.
Implementing it with plain HTML and ordinary hyperlinks (*without*
keeping track of the number of moves made) instead of JavaScript would
have required 838252800 different pages. A difference is that there
is a small, fixed set of images displayed so each one can be manipulated
separately. The game I'm working on will have 1024 cells of which 81 will
be visible at any one time and the contents of the cells can change.

The game relies on Dynamic HTML. The alternative would be plain HTML with
millions of different pages. I have a quota on disk space that wouldn't
allow such a thing and I can't install cgi scripts on my account. It's a
matter of using JavaScript or not doing it at all.
User has image display disabled, alt text shows, your fixed width/height
table is hogging the screen space.
Then the user *can't* use the page.


Can't, or your coding doesn't allow them to?
There is no alt text for background images


Again: CSS should be optional, background images are for decoration,
hence they don't need alt content.


The background images are an essential part of the game. The reason they
are background images is because I have not found any other way to
position two images in the same place and be able to specify which one is
on top.
and none will be appropriate for foreground images.
Using transparent foreground images is a hack.


The alternative is to have a separate image for *every* combination of
foreground and background image that could be possible in the game.
Again, that would eat up my disk quota. A quick calculation shows me I
could need more than 2000 different images to cover all possibilities
needed to implement all of the features of the game when I change the
layout of the current puzzle and I would need several of each image for
each game (up to 80) since many of them would be repeated. It is easier
to hide/unhide a table row or column (to scroll a game map) by setting
the width or height of nine or ten entries to 0px and another nine or
ten to 48px than it would be to keep track of the absolute position and
hidden/visibility status of several thousand separate images, figure out
which are needed at any given time and reposition or hide/unhide the
appropriate ninety of them at a time (9 visible images to be hidden, 72
visible images to be re-positioned and another 9 hidden images to be
positioned and made visible (not counting other things (such as moving
monsters) also having to be changed/moved with the appropraite monster and
background to be selected) just to scroll the player's viewport).

Best would be for me to be able to specify "visibility: collapse" for
those rows and columns that are not in the visible area but that isn't
properly supported by Firefox or Opera yet.
It's for a
*graphical* game. If you can't view images then you can't play the game.


Can't, or your coding doesn't allow them to? If graphics are essential
then the page should relay that to people who do not display images.


It *will* announce that. I didn't think it was necessary for the
*example* page whose URL I posted to this newsgroup.

Can't you take my word for it that I would have used an alternative way
of doing things if a better one was available -- out of laziness if for
no other reason?

It's just that I was surprised that, with Firefox and Opera, borders on
the top and bottom of a table were treated differently than borders on the
left and right and I wanted to know if this behaviour was correct or not
before running off and reporting it as a bug.

Now, are Firefox and Opera doing the right thing or not?
Do you have a reference for your answer?

--
Can you Change: N O V A Halifax to N O V A Halifax *
* S C O T I A . S C O T I A .
in 34 moves? (*==Lobster) http://www.chebucto.ns.ca/~af380/JSNSPuz.html
(Requires a browser supporting the W3C DOM such as Firefox or IE ver 6)

Sep 16 '05 #10

P: n/a

I have created a table in Macromedia Dreamweaver MX 2004 and published
it. In IE it looks like it does in Dreamweaver but in Firefox some
cells are too big. Please help here is the code for the table.

<table width="64" height="185" border="0" cellpadding="3"
cellspacing="3" bordercolor="#99CC66" bgcolor="#99CC00">
<tr>
<th width="52" height="24" bgcolor="#99CC33" scope="row"><p
align="center" class="style1">Home</p> </th>
</tr>
<tr>
<th height="24" bordercolor="#FFFF66" bgcolor="#99CC33"
scope="row"><p align="center" class="style1">About</p> </th>
</tr>
<tr>
<th height="23" bgcolor="#99CC33" scope="row"><div
align="center"><span class="style1">Jokes</span></div></th>
</tr>
<tr>
<th height="23" bordercolor="#FFFF66" bgcolor="#99CC33"
scope="row"><div align="center"><span
class="style1">Reviews</span></div></th>
</tr>
<tr>
<th height="23" bgcolor="#99CC33" scope="row"><div
align="center"><span class="style1">Games</span></div></th>
</tr>
<tr>
<th height="23" bgcolor="#99CC33" scope="row"><div
align="center"><span class="style1">Gadgets</span></div></th>
</tr>
<tr>
<th height="23" bgcolor="#99CC33" scope="row"><div
align="center"><span class="style1">Media</span></div></th>
</tr>
</table>

The adress of the table is

http://www.btinternet.com/~psilas/Ne...pages/test.htm

Any help on this matter would be most appreciated

Thankyou :)
--
jonsey42
------------------------------------------------------------------------
jonsey42's Profile: http://www.highdots.com/forums/m1095
View this thread: http://www.highdots.com/forums/t2927492

Oct 17 '05 #11

P: n/a
jonsey42 wrote:
I have created a table in Macromedia Dreamweaver MX 2004 and published
it. In IE it looks like it does in Dreamweaver but in Firefox some
cells are too big. Please help here is the code for the table. <snip> http://www.btinternet.com/~psilas/Ne...pages/test.htm

Any help on this matter would be most appreciated


Could be because of the error in your styles. Firefox is probably,
correctly, ignoring it.

<http://jigsaw.w3.org/css-validator/validator?profile=css2&warning=2&uri=http%3A//www.btinternet.com/%7Epsilas/New_Smackawhack/pages/test.htm>

--
-bts
-When motorcycling, never follow a pig truck
Oct 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.