212464 - mozilla 1.4 ignores the 'fixed' value for the 'table-layout' style

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[bex]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4) Gecko/20030624

The above URL has 2 pages that display problems with Mozilla 1.4 that do not
exist in 1.3.1, or in IE.  When using JavaScript to increase the 'width' of a
table column, the layout of the table goes crazy. Instead of just two columns
being resized, they all are.

You can reproduce this problem on IE or Mozilla 1.3.1 by simply not using the
"table-layout:fixed" style for the table in the 'resize2.html' sample page.

Hopefully, since this was working in 1.3.1, it wont be a tough fix...

Reproducible: Always

Steps to Reproduce:
1. go to the resize2.html page
2. 'grab' a bar between the table columns
3. drag it to the left or the right


Actual Results:  
all columns explode in size

Expected Results:  
The columns on the left and right of the bar should alter their size according
to how far the bar is pulled. Mozilla 1.3.1 does exactly this.

Comment 1

[Mats Palmgren (inactive)]

-> Tables

Comment 2

[Boris Zbarsky [:bzbarsky]]

The behavior here changed with the checkin to bug 119100.  After that checkin,
table cells, like most elements, follow a content-box sizing model.  Which means
that for a table cell, the offsetWidth is the width + padding + border (since
the width does not include border and padding).

Therefore, setting 

cell.style.width = cell.offsetWidth;

makes the cell bigger by the amount of border+padding.  For that testcase, the
table cells have 1px of padding on each side (set in Mozilla's UA stylesheet)
and so each time you set the width you end up off by 2 more pixels from where
you really want to be.  To test, I replaced the lines:

             var startLeftColWidth = parseInt(leftCol.offsetWidth);
             var startRightColWidth = parseInt(rightCol.offsetWidth);

with:

             var startLeftColWidth = parseInt(leftCol.offsetWidth-2);
             var startRightColWidth = parseInt(rightCol.offsetWidth-2);

and this made things happy.

So the problem is that offsetWidth returns the same thing in both Mozilla and IE
(now and for Mozilla 1.3): the width of the content area, plus border, plus
padding.  However Mozilla 1.3 and IE mis-interpret the "width" style property
for table cells...

One fix that would work for Mozilla is to use:

    var startLeftColWidth =
        parseInt(document.defaultView.getComputedStyle(leftCol, "").width);
    var startRightColWidth =
        parseInt(document.defaultView.getComputedStyle(rightCol, "").width);

This would make the page work with both Mozilla 1.4 and Mozilla 1.3, since the
computed style is always the thing you would want to set as the width property
to get the same rendering.... That won't work in IE, of course.

bernd, is there a bug here?  I don't believe there is, but....

Comment 3

[bex]

I tested this theory with resize3.html and resize3.js, and it doesn't work as
expected... now it works on IE and Mozilla 1.4, but not 1.3. Maybe I didn't do
it right.

Does the CSS spec for table layouts officially state that "offsetWidth" must
exactly equal "width + padding + border" ? So everybody is wrong except for Moz
1.4 and Netscape 7.1?  Wouldn't be the first time  ;)

Even if so, shouldn't setting "table-layout" to "fixed" enforce some additional
restrictions about how much the layout can be changed?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Does the CSS spec for table layouts officially state that "offsetWidth" must
> exactly equal "width + padding + border" ? 

The only spec for offsetWidth is "do what IE does".  So if the table cells are
the same sizes in IE and Mozilla they need to have the same offsetWidth (though
their css widths will be different).  The fun of using nonstandard extensions to
the DOM... ;)

> Even if so, shouldn't setting "table-layout" to "fixed" enforce some
> additional restrictions about how much the layout can be changed?

Not really... All that does is follow as specific layout algorithm, and we are
in fact following it (it just happens that after a few drags the sum of the
specified widths of the cells is larger than the specified width of the table
and the following rule for fixed layout from the spec takes effect:

    The width of the table is then the greater of the value of the 'width'
    property for the table element and the sum of the column widths (plus cell
    spacing or borders). If the table is wider than the columns, the extra space
    should be distributed over the columns.

I'm surprised that the computed style approach is not working with 1.3, though;
I guess the situation there was more broken than I'd thought..... bernd? 
Suggestions?

Comment 5

[Bernd]

I dont see that here is really a bug at all
we return offsetWidth as IE does, we propably did not return the same value in
1.3.1, so this bug seems to be fixed.
Furthermore
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/offsetwidth.asp
indicates that this property isn't defined in any accepted spec. Using this
property and expecting it to work in any other browser than IE looks to me
rather optimistic. 

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is invalid.  What we're doing now makes sense, and there's really nothing
we can do about what 1.3 was doing with that code....