Bug 159575
Summary: | Flexbox: Pseudo elements with `display: table` (ex. clearfix) effect some calculations | ||
---|---|---|---|
Product: | WebKit | Reporter: | ar <webkitbugs> |
Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | ahmad.saleem792, hyatt, jonlee, simon.fraser, webkit-bug-importer, zalan |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 9 | ||
Hardware: | All | ||
OS: | All |
ar
When ::before and ::after pseudo elements (with properties that should make them invisible) are applied to an element that also has `display: flex`, Safari includes those pseudo elements in the flexbox calculations.
The most common case would be applying a clearfix to the container:
.clear-fix:before,
.clear-fix:after {
content: "";
display: table;
}
.clear-fix:after {
clear: both;
}
Result:
- Children elements, that are *specifically* set to flex and grow behave in an unexpected way because Safari is actually applying various flexbox calculations to those *actual* elements AND the pseudo elements.
- IOW: If there are 3x child elements, Safari calculates some (but not all) flexbox properties for 5 elements (3 + ::before, ::after).
- In some cases (depending on the flex attributes for container and children) this results in a 1-3px gap between the edge of the container and the *actual* (non-pseudo) first or last element.
- In other cases, where there are two *actual* elements that should each occupy 50% of the container's width, the second child will be pushed down to the next line (since that 1px, from the clearfix, will cause the second element, at 50%, to not have enough room on the same line).
This person (Dan Bissonnet) did a very nice write-up and test case:
http://danisadesigner.com/blog/flexbox-clear-fix-pseudo-elements/
http://codepen.io/dbisso/full/cCBpn
However, his solution (flex-basis: 0; order: 1), didn't work in the specific case where I originally found it.
I found 3x alternate workarounds (properties added to ::before and ::after):
- `display: none;` <-- My chosen solution
- `position: absolute`
- `display: flex`
`visibility: collapse` (which is flexbox specific and supposed to be similar and `visibility: hidden`) is NOT a workaround.
See:
http://www.w3.org/TR/css-flexbox-1/#visibility-collapse
Luckily, in my case, I didn't really need those clearfixes, so `display: none` (or, if you can, removing the clearfix entirely) works well. But if you need them, I'm not sure any of these workarounds are complete.
I'm not sure if you'll classify this as a bug because I can see a case for this being the intended behavior OR chalk it up to the flexbox spec not being specific enough for a case like this (child element = `display: table`).
However, I'm reporting because I don't know the definitive answer AND it's *not* an issue in Chrome (51.0.2704.103) or Firefox (47.0.1). It seems to correctly collapse or not *count* the pseudo elements as flexbox children.
Possibly related reports:
https://bugs.webkit.org/show_bug.cgi?id=152783
https://bugs.webkit.org/show_bug.cgi?id=140543
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Jon Lee
<rdar://problem/29695092>
Dave Hyatt
This does still happen. I don’t think it’s a flexbox issue, but an issue with us deciding the table should be 1px wide (when Blink thinks it should be 0).
ar
Thanks for the update.
> I don’t think it’s a flexbox issue, but an issue with us deciding the table should be 1px wide (when Blink thinks it should be 0).
Ahh.
That makes sense.
Here's what I think are some related posts (just for cross-referencing):
https://bugs.webkit.org/show_bug.cgi?id=39381
http://stackoverflow.com/questions/5761145/webkit-safari-and-chrome-zero-width-td-with-only-bottom-border-is-displayed-as?rq=1
http://stackoverflow.com/questions/24331082/chrome-displaying-table-cell-with-0-width-as-1px
http://stackoverflow.com/questions/30822405/automatic-1px-width-of-div-inside-table?rq=1
Ahmad Saleem
From CodePen in Comment 0, I am not able to see any "yellow" line on both end of the containers in Safari 16.1 and Safari matches with Chrome Canary 109 and Firefox Nightly 109.
I am marking this as "RESOLVED CONFIGURATION CHANGED" and related bugs are also closed (IMO - since I am not able to reproduce them either). Also I think Webkit also removed 1px hack.
Please reopen, if you think this issue is still reproducible. Thanks!
ar
(In reply to Ahmad Saleem from comment #4)
> From CodePen in Comment 0, I am not able to see any "yellow" line on both
> end of the containers in Safari 16.1 and Safari matches with Chrome Canary
> 109 and Firefox Nightly 109.
Agreed.
It looks accurate even in slightly older version of Chrome (130) and Firefox (78).
> I am marking this as "RESOLVED CONFIGURATION CHANGED" and related bugs are
> also closed (IMO - since I am not able to reproduce them either). Also I
> think Webkit also removed 1px hack.
Yes. I guess some other change fixed this.
> Please reopen, if you think this issue is still reproducible. Thanks!
Thank you.