Bug 18153 – table not aligned in center column and seems shrunk because of float:right (table-layout: fixed and width: 100%)

• Status: RESOLVED
• Resolution: FIXED
• Component: Tables

[jasneet]

I Steps:
Go to 
http://shopping.busca.uol.com.br/informatica/computador/index.html?q=computador&search=yes&subsearch=true&rtrk=src:12;size:18;chn:103;thm:PCS+499

II Issue:
The table of listed items is not aligned in center column rather has shrunk and moved to right side of the page. 

III Conclusion:
The testcase uses <col> tags to define the width of the columns of the table. However it seems that Safari does not apply the correct width for each column because of the float:right property of the <div> surrounding the table.

If I remove the float:right of the <div> then Safari renders the columns same as FF and IE.

IV Other browsers:
IE7: ok
FF3: ok
Opera9.24: ok

V Nightly tested: 31315

[jasneet]

Created attachment 20130 [details]
screenshot

[jasneet]

Created attachment 20131 [details]
reduction

[Arpita Bahuguna]

The issue associated with the failing URL (i.e. a shrunk table displayed on the right side) is now no longer reproducible. (verified for WebKit revision  131989).

However, for the attached reduction, we behave differently from FF.

This is due to our different handling of fixed table layout in non-quirks mode; when compared against FF's behavior.

This is in accordance with http://trac.webkit.org/changeset/48647 which adds a check for preferred logical width calculation in fixed layout algorithm for tables having percent width. The check is specific for quirks mode.

In quirks mode, we expand the table to its max possible width; ignoring the computed fixed layout algorithm width. For standard mode however we restrict our width to that of the computed value.

This issue can perhaps be closed since this seems to be our normal behavior.
Also see: http://trac.webkit.org/changeset/4316

[Robert Hogan]

Arpita seems right to me but it would be good to find the part of the spec that confirms it, just in case that FF is the only doing this right!

[Arpita Bahuguna]

(In reply to comment #4)
> Arpita seems right to me but it would be good to find the part of the spec that confirms it, just in case that FF is the only doing this right!

Hi Robert, apologize for the late reply.

I did check the fixed table layout specification (http://www.w3.org/TR/CSS2/tables.html#fixed-table-layout) and to me it seems that our behavior is probably not right.

According to the specification:
    In the fixed table layout algorithm, the width of each column is determined as follows:

    1. A column element with a value other than 'auto' for the 'width' property sets the width for that column.
    2. Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property determines the width for that column. If the cell spans more than one column, the width is divided over the columns.
    3. Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing). 
    
Applying the same to the table in our reduction, we would thus have a specified width for each of our columns (which adds up to: 732px on win-safari). The specification then goes on to say:

    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. 
    
Now, for our reduction, the table width has been specified as 100% which would be greater than the sum of our individual column widths and going by that, ideally, our table should be spread across the full length of the containing block, the way Mozilla behaves; and so would we if we were to remove the quirks-mode check added in void FixedTableLayout::computePreferredLogicalWidths().

I also didn't find anything in the specification that would corroborate our handling of the quirk fixed in http://trac.webkit.org/changeset/48647.

Moreover, I tried to execute the tests added for http://trac.webkit.org/changeset/48647 (fast/table/fixed-table-with-percent-inside-percent-table.html).
To the test if I were to add a standard mode doctype (e.g. HTML5 doctype) we fail this same test, whereas the other browsers pass it.
This is again due to the quirks mode check added in void FixedTableLayout::computePreferredLogicalWidths() as part of http://trac.webkit.org/changeset/48647.

Am not so sure as to whether this check (for quirks mode) is required (anymore). If we were to remove the same, we would then start behaving like FF even for the original issue mentioned in this bug.

Would really appreciate your comments on the same. I shall also try uploading a patch with the change and look for any possible regressions.

[Arpita Bahuguna]

Created attachment 172780 [details]
Patch

[Beth Dakin]

Comment on attachment 172780 [details]
Patch

Table changes always scare me, but this seems well-researched. r=me.

[WebKit Review Bot]

Comment on attachment 172780 [details]
Patch

Clearing flags on attachment: 172780

Committed r134017: <http://trac.webkit.org/changeset/134017>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.