RESOLVED DUPLICATE of bug 289441290444
Button with Column Flex Layout Does Not Expand Child Flex Containers to Full Width
https://bugs.webkit.org/show_bug.cgi?id=290444
Summary Button with Column Flex Layout Does Not Expand Child Flex Containers to Full ...
thecloer
Reported 2025-03-26 00:45:03 PDT
Created attachment 474720 [details] compare the result of the example code in chrome and safari When a `<button>` element styled as a column flex container (using `display: flex; flex-direction: column;`) contains child flex containers, the children do not expand to the full width of the parent. As a result, inner elements that rely on `margin-left: auto` for right alignment do not behave as expected. **Description:** The following HTML example demonstrates the issue: ```html <style> .wrapper { display: flex; flex-direction: column; text-align: left; width: 200px; } .content { display: flex; } .right { margin-left: auto; } </style> <button class="wrapper"> <div class="content"> <div class="right">content</div> </div> <div class="content"> <div class="right">content</div> </div> </button> ``` Expected Behavior: Each child flex container (`.content`) should expand to the full width (200px) of its parent (`.wrapper`). This would allow the `.right` element—with `margin-left: auto`—to align to the right as intended. Actual Behavior: In Safari, the child flex containers only size themselves based on their content. They do not expand to occupy the full width of the parent button, causing the `margin-left: auto` property on the inner `.right` elements to have no effect. Additional Information: - The issue appears to be specific to Safari’s handling of flexbox on `<button>` elements when using a column layout. - The same code behaves as expected in other browsers (e.g., Chrome), where the child flex containers correctly stretch to fill the parent’s width. - A simplified test case is provided in the code snippet above.
Attachments
compare the result of the example code in chrome and safari (46.73 KB, image/png)
2025-03-26 00:45 PDT, thecloer
no flags
testcase 01 (722 bytes, text/html)
2025-04-07 21:08 PDT, Karl Dubost
no flags
rendering in safari, firefox, chrome (1.27 MB, image/png)
2025-04-07 21:10 PDT, Karl Dubost
no flags
Karl Dubost
Comment 1 2025-03-27 19:36:52 PDT
Thanks for the report. Firefox is giving the same result than Chrome.
Radar WebKit Bug Importer
Comment 2 2025-04-02 00:46:21 PDT
thecloer
Comment 4 2025-04-07 19:00:30 PDT
This is a simplified version of the example code. ```html <style> .container { display: flex; flex-direction: column; /* styles */ gap: 5px; width: 200px; } .item { display: flex; /* styles */ background-color: red; min-width: 50px; height: 15px; } </style> <h1 data-title></h1> <button class="container"> <div class="item"></div> <div class="item"></div> </button> ```
Ahmad Saleem
Comment 5 2025-04-07 19:31:11 PDT
https://html.spec.whatwg.org/multipage/rendering.html#anonymous-button-content-box If the element is an input element, or if it is a button element and its computed value for 'display' is not 'inline-grid', 'grid', 'inline-flex', or 'flex', then the element's box has a child anonymous button content box with the following behaviors: The box is a block-level block container that establishes a new block formatting context (i.e., 'display' is 'flow-root'). If the box does not overflow in the horizontal axis, then it is centered horizontally. If the box does not overflow in the vertical axis, then it is centered vertically. Otherwise, there is no anonymous button content box.
Karl Dubost
Comment 6 2025-04-07 21:08:13 PDT
Created attachment 474865 [details] testcase 01 This is the testcase for the first code provided.
Karl Dubost
Comment 7 2025-04-07 21:10:05 PDT
Created attachment 474866 [details] rendering in safari, firefox, chrome This is the rendering in Safari Technology Preview 216 / 18.4 20622.1.7.2 Firefox Nightly 138.0a1 13825.3.20 Google Chrome Canary 137.0.7113.0 7113.0 So I guess the issue is solved in recent versions of Safari.
Karl Dubost
Comment 8 2025-04-07 21:10:57 PDT
thecleor could you double check in STP 216.
thecloer
Comment 9 2025-04-07 21:37:43 PDT
I just checked it in STP 216 and it looks solved that version. Thank you for your prompt response. I'm sorry for taking up your time; next time, I'll make sure to check STP as well.
Karl Dubost
Comment 11 2025-04-08 00:46:12 PDT
no issue and you're welcome.
Karl Dubost
Comment 12 2025-04-08 00:46:49 PDT
*** This bug has been marked as a duplicate of bug 289441 ***
Note You need to log in before you can comment on or make changes to this bug.