Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 343e13bf22dca9d0ec227801419aab0f9001a32f
https://github.com/WebKit/WebKit/commit/343e13bf22dca9d0ec227801419aab0f9001a32f
Author: Alan Baradlay <[email protected]>
Date: 2026-04-28 (Tue, 28 Apr 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/css/css-position/position-absolute-table-001-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/css/css-position/position-absolute-with-negative-sized-imcb-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/css/css-tables/absolute-tables-002-expected.txt
M Source/WebCore/rendering/RenderBox.cpp
Log Message:
-----------
Fix imported/w3c/web-platform-tests/css/css-tables/absolute-tables-002.html
https://bugs.webkit.org/show_bug.cgi?id=313470
Reviewed by Antti Koivisto.
When an absolutely positioned table has a CSS width smaller than its
content, the table expands to fit the content (the used width of a table depends
on the columns and captions of that table), meaning CSS width acts as a minimum
- the
table layout algorithm can produce a larger used width when cell
content requires it. But the position was computed using the CSS width,
not the expanded width, so the table overflowed its containing block.
For example:
<div style="position: relative; width: 300px;">
<table style="position: absolute; width: 100px; right: 0;">
<td><div style="width: 200px;"></div></td>
</table>
</div>
The constraint equation for absolutely positioned elements is:
left + margin-left + width + margin-right + right = containing block width
Before:
RenderBox::computeOutOfFlowPositionedLogicalWidth
usedWidth = 100 (from width: 100px)
computedValues.extent = 100
resolvePosition -> left = 300 - 100 = 200
RenderTable::updateLogicalWidth
setLogicalWidth(100) (from constraint equation)
setLogicalWidth(100) (from style)
setLogicalWidth(max(100, 200)) = 200 (content expansion)
// but logicalLeft is still 200!
Result: left=200, width=200, right edge at 400. Overflows.
After:
RenderBox::computeOutOfFlowPositionedLogicalWidth
usedWidth = 100 (from width: 100px)
usedMinWidth = max(min, 200) (from minPreferredLogicalWidth)
usedWidth = max(100, 200) = 200 (content floor applied)
computedValues.extent = 200
resolvePosition -> left = 300 - 200 = 100
Result: left=100, width=200, right edge at 300. Flush.
The fix adds a content-based minimum width floor for tables in
computeOutOfFlowPositionedLogicalWidth, right where min-width is
already handled. This is the same mechanism that makes
"min-width: max-content" work correctly for flex containers -
the expansion happens inside the constraint solver, so the position
is computed using the final width.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-position/position-absolute-table-001-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/css/css-position/position-absolute-with-negative-sized-imcb-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/css/css-tables/absolute-tables-002-expected.txt:
* Source/WebCore/rendering/RenderBox.cpp:
(WebCore::RenderBox::computeOutOfFlowPositionedLogicalWidth const):
Canonical link: https://commits.webkit.org/312197@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
