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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 30 06:22:31 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=18153





--- Comment #5 from Arpita Bahuguna <arpitabahuguna at gmail.com>  2012-10-30 06:23:48 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list