[Webkit-unassigned] [Bug 136439] New: Table auto-layout renders oddly in certain cases where colspan

[bugzilla-daemon at webkit.org]

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

           Summary: Table auto-layout renders oddly in certain cases where
                    colspan
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
        OS/Version: Mac OS X 10.9
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tables
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mike.ihde at gmail.com


Created an attachment (id=237467)
 --> (https://bugs.webkit.org/attachment.cgi?id=237467&action=review)
Example demonstrating the issue

What steps will reproduce the issue:
-------------------------------
I noticed this issue when comparing one of my websites when rendered via Firefox versus WebKit-based browsers.  I originally reported the issue under Chrome (https://code.google.com/p/chromium/issues/detail?id=122551).  Recently I decided to investigate the issue because years later I'm still seeing the same rendering issue.

The attached test HTML also demonstrates the issue.  In Firefox the 100% width column fills all remaining space.  In WebKit the fixed with columns #2 and #3 receive extra width.  Oddly enough, if you avoid using colspan in the second row (i.e. have 5 empty cells) then WebKit makes the same rendering decision as Firefox.

I fully understand that the use of tables in this context is a bit of an anachronism that is much better suited to CSS-based layouts. 

Expected Result
--------------
This is a tricky question.  Personally I believe that the approach that Firefox uses is most intuitive and WebKit should follow suit.  Because CSS  2.1 claims "UAs are not required to implement this algorithm to determine the table layout in the case that 'table-layout' is 'auto'; they can use any other algorithm even if it results in different behavior" there isn't an unambiguous right answer.  In other words, perhaps this isn't really a bug.

Reading the CSS3 table layout draft, still leaves a bit of ambiguity.  It appears that WebKit is treating this special case using combination #9...however, I think that combination #3 could also be considered appropriate depending on how you interpret the special case "where the percent columns are demanding the full table width (100%) but there are also non-percent columns which require at least their minimum width."


Furthermore, it would seem that the column width decided for the first row should not be affected by the colspan usage in the second row.

Possible Resolution
----------------
After hacking around I found some suspect logic in calcEffectiveLogicalWidth() near the line that says:

        // Give min to variable first, to fixed second, and to others third.

If I simply removed the "&& haveAuto &&" check the page rendered as I would expect.  I have not yet determined if this would introduce any undesired behavior, so it's probably not the correct fix.

It also seems that if the table actually has an auto-sized column, the code might actually be distributing width to fixed first than variable.  Perhaps the code is correct and the comment is mis-leading.

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