Bug 136439 – Table auto-layout renders oddly in certain cases where colspan

• Component: Tables
• Status: NEW

[Michael Ihde]

Created attachment 237467 [details]
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.

[Ahmad Saleem]

I fixed the test case with Webkit logo:

Link - https://jsfiddle.net/bk52o3js/show

Safari 16 and STP 156 differs in first row from Chrome Canary 109 and Firefox Nightly 109 but the issue seems to be highlighted in various other bugs where the table cell does not respect min-width or width aligned with the fill or content. I think we can mark this close but I would leave others to comment. Thanks!

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #1)
> I fixed the test case with Webkit logo:
> 
> Link - https://jsfiddle.net/bk52o3js/show
> 
> Safari 16 and STP 156 differs in first row from Chrome Canary 109 and
> Firefox Nightly 109 but the issue seems to be highlighted in various other
> bugs where the table cell does not respect min-width or width aligned with
> the fill or content. I think we can mark this close but I would leave others
> to comment. Thanks!

Reading through Possible Resolution - It is referring to following:

https://searchfox.org/wubkat/source/Source/WebCore/rendering/AutoTableLayout.cpp#432