Closed
Bug 1818
Opened 26 years ago
Closed 26 years ago
Rendering of tables with fixed width columns
Categories
(Core :: Layout: Tables, defect, P4)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: luis.ferro, Assigned: buster)
Details
Attachments
(7 files)
When building a Webpage with a table with 3 columns and fixed the width of two
and leaved the third unspecified.
When i resize the browser window (in the width also), i was expecting to see the
fixed columns to remain fixed and the variable one to change size. But instead,
i've all of them to resize.
Also, when i specify the columns with a precise dimention the last one always
become with a smaller size then the sum of all widths should indicate, even if
paddings, spacings and borders are zero.
When creating a table with an image inside, a table with just one cell with the
exact size of the image, it leaves a annoying space in the left and bottom
sides. This is normally used to add a frame to an image.
The submitter sent me this excellent report included below. Unfortunately, the
report doesn't match the comments in the bug report. Can the submitter please
clarify? I don't see anything in the report about an image in a table cell --
specific HTML source would be helpful here. Likewise for the first part of the
bug report, it seems in the report you say NGLayout behaves well, but you report
the behavior as a bug here. I'm a bit confused.
====================== ORIGINAL REPORT ========================
Rendering of Tables (a case study)
Objective
Acertain how does diferent browsers and the NTG renders the tables and
how it should render them. For starters, the table tags. The tests are to meet
the W3C specs of html 3.2.
Case code:
<html>
<head>
</head>
<body>
<TABLE BORDER=2 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" height="50">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC">
<TD WIDTH=6 BGCOLOR="#00CC00">
<TD BGCOLOR="#CC0000">
</TABLE>
</body>
</html>
There will be made minor modifications to the code to check some troubles of the
rendering.
The NGT viewer used is the one as of nightly build in 10Dec98. Netscape
Comunicator is 4.5 [en] 98293, Opera is 3.5 Build 3.50.0.238, Win32, and IE4 is
version 4.72.3110, SP1. The code will be modified and then tested with all those
browsers, all behavors will be stated and what should had happen also (this
according with my belives and the reading of the W3C Specs - which are an
interpretation). With the W3C specs i will look first at the specs itself and
then on the recomendations (which aren't mandatory).
First Round - The test code
The code as is...
Results:
NTG - Renders the table correctly, that is, placing the first two
columns with the stated size and with the border arround the first two columns.
The border arround the third column is rendered just a bit and falls in it's
right side behind the column itself (i think this is a bug). If one minimizes
and restores the window the column apears ok then.
IE4 - Renders it as NTG but with the border well rendered arround all
columns.
Communicator - Increases the first column absurdelly to the right, not
respecting the width of it. On the other and, leaves the third column very
small, when this would be the variable width column and could be with any size.
Border rendered OK.
Opera - Renders the columns with much increase width. Border Ok.
Conclusion - The render of columns with cells with a fixed size seams ok in NTG,
but there's a small glitch in the border rendering. The opera and the netscape
assigned leftover space in diferent ways, each of them not very nice ones. Opera
distributed the leftover space evenly on all columns (which is only recomended
by W3C, but isn't complyent with the specs of column width which state that the
width and height must be respected except in the case of when it conflicts with
other columns/rows - which wasn't the case). Communicator solution is very
masty, it assigns the leftover space in the first column which isn't also in
accordance with the specs of the width/height parameters.
Second Round - Let's close the tags
In this case we just added </td> and </tr> when apropried. Those tags aren't
mandatory in W3C Specs, but we would like to see if there where any diferences
in the rendering:
<html>
<head>
</head>
<body>
<TABLE BORDER=2 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" height="50">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC"> </TD>
<TD WIDTH=6 BGCOLOR="#00CC00"> </TD>
<TD BGCOLOR="#CC0000"> </TD>
</TR>
</TABLE>
</body>
</html>
Results:
The only diference was in Communicator which rendered the right column even
smaller, and allocated the space in the left column. There shouldn't be any
diference...
Third Round - Render test
As in W3C the border is only rendered if there's content. The spcecs don't say
that the cell doesn't need to be rendered, so we will remove all contents and
check if the "background" areas are rendered as they should. The expected
behavor would be to render the table cells, but not present any border...
<html>
<head>
</head>
<body>
<TABLE BORDER=2 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" height="50">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC">
<TD WIDTH=6 BGCOLOR="#00CC00">
<TD BGCOLOR="#CC0000">
</TABLE>
</body>
</html>
NTG - Renders only the first column with a border. Doesn't place any
background color.
IE4 - Renders the table as it was previously, and without border
between cols, which is correct.
Communicator - Renders a table with the size of what it was previously, but
without any background color. Doesn't place any border between the cols either
which is correct.
Opera - Renders it exactly as it was, and without border between cols,
which is correct.
Conclusion - Only Opera and IE4 rendered the table correctly, the others
rendered only part and even that wrongly...
Fourth Round - Window resize
We wanted to check the behavor of all browsers to a window resize in the
horizontal plane.
<html>
<head>
</head>
<body>
<TABLE BORDER=2 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" height="50">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC">
<TD WIDTH=6 BGCOLOR="#00CC00">
<TD BGCOLOR="#CC0000">
</TABLE>
</body>
</html>
The windows where minimazed, then restored, then resized horizontally.
(this is the same as the first test code)
NTG - Resizes everything as expected, only resizeing the fixed columns
if the window is too small and even then proportionally. This is nice.
IE4 - As with NTG.
Communicator - As the first render is very defective this test isn't conclusive,
but all resizings are made at the cost of the first column (which was the one
that have excess size).
Opera - Redistributs all space evenly til the screen is too small.
Doesn't resize the columns with less than the stated size which is the only one
doing that.
Conclusion - The tables are better in NTG and IE4, but opera shown to be the
only one to respect the minimum size of the columns. Communicator falled back in
this test also...
Overall:
NTG is a very good improve over Communicator, with only a small glitch in the
border rendering and if it respected the fixed column sizes it would be nice.
The specs state that the minimum size should be only not respected it colides
with other cols/rows, so if the window isn't big enought to show the table, a
scroll bar should be places, not shrink the table beyond recognition...
IE4 shown that it is already there, but... is Micro$oft...
Communicator falled way back in all tests showing that needs much polish in the
table rendereing.
Opera shown an excessive compliance to all W3C Specs in some areas and didn't
respected the size of the columns when rendering, but complied with them when
the window was resized, which if an odd behavor...
Next mail analisis, Span of columns & rows and alignments
Thanx for your paciance,
Luis Ferro
P.S.- the strange behavor of opera will be send to them as well.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
The submitter followed up with the note included below. In response to the note:
NGL lays out the first case correctly. The third column is the only column
resized until the container width is less than the sum of the specified column
widths, at which time the column widths are shrunk to fit in the container.
For the second case, the issue is the rendering of cell backgrounds when the
cell has empty content. Nav4 only renders cell backgrounds when the cell has
some content (other than generic whitespace) NGL renders backgrounds on all
cells, which seems to be the intention of the W3 specs. We could easily make
background rendering depend on whether the cell has any content, but that seems
to be replicating a Nav4 bug rather than carrying forward a desired behavior.
============== SUBMITTER'S NOTE =================
I'm a bit impressed with the speed of the answer ;)
Well, i've seen this behavor everywhere on every browser that i've
tryed:
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC"> </TD>
<TD WIDTH=6 BGCOLOR="#00CC00"> </TD>
<TD BGCOLOR="#CC0000"> </TD>
</TR>
</TABLE>
In this case, the behavor should be the table to resize only the third
colums, but mantaining the integrity of the two first ones as they are
fixed. In all browser i've tryed what happens is that all are
re-rendered. I've still to check in W3C specs but i don't think that it
was intended that way...
That's why almost everyone has to use tables inside tables to archive
something that should be easy to do if the specified dimensions where
respected.
Also, i've found that if there isn't info in the columns at all, the
table isn't rendered correctly:
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%">
<TR>
<TD WIDTH=400 BGCOLOR="#0000CC"></TD>
<TD WIDTH=6 BGCOLOR="#00CC00"></TD>
<TD BGCOLOR="#CC0000"></TD>
</TR>
</TABLE>
In this case the table is rendered by IE4 as a single line (and with
only two columns), and isn't rendered either by Opera 3.50, nor
comunicator.
As i was writing this i've found that a build of gecko was available for
win32... i will be back soon with an analisis of the table
interpretation... and i will see also the specs...
Sorry if i was so superficial in the bug description... i just hope that
i can give you suficiently detailed info as to increase the great value
of mozilla has to the community already...
Thanx in advance,
Luis Ferro
|
||
Comment 3•24 years ago
|
||
|
|
||
Comment 4•24 years ago
|
||
|
|
||
Comment 5•24 years ago
|
||
|
|
||
Comment 6•24 years ago
|
||
|
|
||
Comment 7•24 years ago
|
||
|
|
||
Comment 8•24 years ago
|
||
|
|
||
Comment 9•24 years ago
|
||
|
|
||
Comment 10•24 years ago
|
||
It seems that all testcases except testcase 3 are rendered correctly now after
bug 19961 has been fixed. In testcase 3 in quirks mode the buggy behaviour of
Nav4 is repeated , no internal borders are drawn. In the strict mode these
borders are shown as demonstrated by the last testcase. I would mark this bug as
verified, but every time I touch one of buster's bugs he scares me to death by
unfriendly emails. :-)
You need to log in
before you can comment on or make changes to this bug.
Description
•