5797 - Cell width calculation problem, when specified cell width is very large

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[Péter Bajusz]

The width of the two cells should have a ratio _around_ 1:2
It's OK both in ie4 and ns4.5, but has problems in mozilla.
The extra space in the table is not distributed
between the cells, but added entirely to the 2nd cell.

Checked M4 and 1999042908
-----------
<table border>
  <tr>
    <td width=2000>x</td>
    <td width=4000>y</td>
  </tr>
</table>

Comment 1

[karnaze (gone)]

Moving to M9.

Comment 2

[Péter Bajusz]

I cannot simplify the testcase any more.
Duplicating as an attachment for easier viewing from the browser.
Changing summary to better describe the problem.

Comment 3

[Péter Bajusz]

Attachment: Testcase (same as the one in the description)

Comment 4

[Chris Booton]

It appears that if the widths speified are greater then the pixeld available on
your minitor that it does not displayed it corectly . Im at 800x600 and did a
400 width and another 400 width and it works, I'll attach the file so you can
see for yourself. Perhaps it's doing it that way as it's getting confused by the
numbers being high and is only giving the first cell how much it needs to
display it's contents and the second cell gets the rest of the screen width?

Comment 5

[Chris Booton]

Attachment: This is using 400 and 400 width and it displayes properly

Comment 6

[Chris Booton]

In 4.5 what it does is to calculate each cells width in pixels as a % of the
total of each cell, notice that in the example no total width is given, so 100%
is assumed which is correct. I think a fix for this would simply be if no width
for the table is specified then assume 100%, and if the total pixels of each
cell are more then the screen pixel width then add up to total pixels it wants
and take each ones as a 100% of the total and use that as the width in 100% (if
say you have three cells and 800 width available. 1 wanted 400  2 wanted 600 and
3 wanted 1000 for a total of 2000 , so for 1 400/2000 = 20% , for 2 600/2000 =
30% and for 3 1000/2000 = 50% for a total between the three of 100%. Would this
be an acceptable fix?

Comment 7

[Péter Bajusz]

The contest is a contest, eh?

I don't actually see your point with your 400 pixel example.
Change the width to 2000 in both cells in your example, and it still works.
And 2000 is likely larger than your screen width.
(I'm not creating a testcase for that.)

Also the issue is not that simple as you say in your second comment.
Cells based on their content has a minimal width, a "maximal" width, and
a "specified" width (at least).
(Someone might be able to correct my terminology.)
If all the cell contains is text, then the minimal width is the width of the
longest word, the maximal width is the length of the longest possible line of
the text.
I you watch how NS4.6 divides the space, you'll see that the amount each
cell gets is dependent on the maximal width as well as the specified width,
even if the specified width is the larger.

Back to the bug, it seems to me that how it calculates currently is:
give all the cells their specified width (in this case at least when its larger
than the maximal width), and when it's larger than the available width (of the
window), then it's trying to _substract_ an equal amount from each cell, until
the resulting table fits.
This way if the first width is X and the second one is Y, and X+Y is larger than
the available width A then the divider between the cells end up being at
A/2 - (Y-X)/2
So if X=2000 and Y=4000 as in my example, than it's trying to put the divider
about 1000 pixels left from the half of the window, so the first cell ends up
having its _minimal_ width.
If you change X=500 and Y=1000 you can watch it behave as you resize the window.
If you also change the content of the 1st cell from "x" to "x x", you'll see
proof, that it gets to its minimal width, ignoring the maximal width unlike
NS4.6

Comment 8

[Chris Booton]

I see what your saying, then presumibly the correct way for it to do it in your
example is to calculate A how many pixels are available in total, then to see
how many are being requested by x+y, if it's too large then give the firts one
the minimum it needs to display it's contents and then give the rest to y, which
is as you say not correct.

How about if it calculated the minimal width of each and totalled that up, if
this is less then what you have available and a 100% width is requested , then
take how many pixels are left and divide that amoung the total amount of cells
and give the resulting amount of cells to each available one. But it would have
to take into account what is being asked for in the width property of <td>, as
doing it the above way would give both cells 50% even though one asks for twise
what the other asks for. What would be a good way to do this?

perhaps the way I sugested of adding up whats of the total of the two widths is
being requested and giving each one a % of the total which is based on the % of
the total it asked for. But if in doing this a cell ends up getting less then
it's minimal , and other cells could stand to loose some pixels without the
pixels going to them becoming less then their minimal, then an even number would
be taken from other availbe cells until enough pixels become avaible to give to
the cell needing extra to attain it's minimal width? This sounds very
complicated though, say if you have 800 pixels and someone put's in an 800 pixel
wide image in cell 1 , and in cell 2 they have some text needing minimal 8
pixels in it. the only option here would be to make the table > 100% by the
minimal required to give each cell it's minimal width.

Example of the above, requested 100% width (800 pixels on the persons screen),
cell one guessed at 500p cell two at 300p. There is an image in cell 1 thats
800x600. It would know that 500p being asked for , for cell 1 is not enough and
300p is too much for cell 2 (or at least it's way over the min.) . then
logically it would have to take from cell 2 the min amount of extra p's it
needs (300p), but this leavs c#2 with 0, so it would have to extend the table
beyond the screen and put in a scroll bar to give the text cell (#2) what it's m
is.

Would this work. is this how 4.xx does it?

Comment 9

[Chris Booton]

Attachment: test using numbers like in my example, lets see what happenes

Comment 10

[Chris Booton]

I tested it in todays build under win98, and it does the same as 4.5 for the
first table (since the two cells reuire more then the available width it gives
each it minimum needed), but for the second one it gives using text in three
cells it gives #1 and #2 their min, the #3 the rest. I still stand on that in
the second table it should give the % value for each a number based on what
total the three were asking for, then the % of that each one wanted (provided
that giving one that % is not < the min.) if it is I guess it would need to take
from one of the others that can afford to loose some pixels.

Comment 11

[Hixie (not reading bugmail)]

*** Bug 5232 has been marked as a duplicate of this bug. ***

Comment 12

[Hixie (not reading bugmail)]

Don't mind me...

Bug 5232, which I have just made a duplicate of this bug, has tables and nested
tables with many cells with widths of 100%. Mozilla is using the CSS definition
of width, and making the table wider than its specified size of 100%.

The original test page from that bug is at:
   http://www.microsoft.com/dns/ecommerce/Starbuck.htm

IE4 (and presumably NN4) render the table with a width as specified on the
TABLE element, and thus do not make the page wider than the viewport.

Comment 13

[Chris Booton]

Looks as if bug#2763 is simular to this one, same type of problem. If it's not a
duplicate then I would mark it as depends on it as the effect is the same.

Comment 14

[Chris Booton]

Attachment: again using width=100% and asenine values in the <td width=, but what happens when one image fails to load (the first one)?

Comment 15

[Chris Booton]

In 4.5 what seems to happen is that it simply uses that ratio's of what each td
width was aksing for to determine what of the 100% it needs. But in 5.0 image
one (which doesent show up), is given one pixel, image two is given a lot of
spcae and the text at the end is given it's minimum needed, seems like instead
of giving each their minimum and then giving whats left to the middle cell that
it should divide what left amooung each cell.

I have a sugestion to fix this bug, in the case of the pixels being requested
for the <td width's=> totalling more then the avaible screen width (or less
then what is being asked for), give each cell it's minimum reuired pixels to fit
it's contents in  (ie width of biggest image in it and/or length of longest
word) then take however many pixels you have left and divide it up evenly amoung
each cell. This may not be the totally correct way to interpret it but it seems
like the most efficient and is worth a try if it means fixing this bug and the
many that are related and/ore duplicates of it.

Comment 16

[John Morrison]

This bug report began with a simple, concrete statement of a problem by hyp-x.

To quote [e-mail] on bug #5024:

    "This is exactly what should _not_ happen with a bug report. The
     original bug report has turned into several different problems."

 The goal is not to expand all bugs related to 'table too wide' into one omnibus
bug; rather, the goal is to reduce a specific problem to a simple, reproducible
testcase. Then, let the developers figure out how they want to deal with it.

 Specifically, csbooton has noted on other bug reports that (at least) bug
#6388 and bug #3977 are duplicates of this bug.

 bug #6388 involves 'colgroups and relative/proportional width'; bug #3977
involves 'colspanning of replaced elements (IMG)'. The examples in this page
(#5797) are single row tables that use fixed widths.

 Those are three distinct code paths.

 In the interest of improving the signal-to-noise ratio and letting Chris
Karnaze spend his time on concrete problem-definitions, please stop implying
that other bugs are 'duplicates' simply because they refer to a problem with
table widths.

Comment 17

[John Morrison]

Yes, this is more unfortunate noise, but I must correct the beginning of my
comments; what I had intended to say was:

 > This bug report began with a simple, concrete statement of a problem
 > by hyp-x.  Now, it is a complicated listing of various comments, and
 > testcases that introduce other issues and elements.
 >
 > To quote [e-mail] on bug #5024:

My apologies to hyp-x for the unintended reading of the previous comment.

Comment 18

[karnaze (gone)]

Fixed width 7/28 changes.

Comment 19

[Christine Hoffman]

Using 8/16 Apprunner, verified fixed