You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firefox has been shipping parts of the continue: collapse proposal (see #7708 and #10816) in their implementation of -webkit-line-clamp, which included hiding content after the clamp point. For absolute positioned elements, they would be hidden if they are after the clamp point in the layout tree, regardless of where they are positioned.
However, this abspos behavior seems to break the web. Firefox got three different bug reports (bugs 1934547, 1934811 and 1936267), one of which affecting LinkedIn, where an absolutely positioned element that was placed at the end of a line-clamp container (or in an ::after pseudoelement) but positioned to show before the clamp point was expected to be visible. In two of these three cases, these positioned elements were the "Show more" button that would turn off line-clamping.
All of these cases use -webkit-line-clamp together with overflow: hidden, so absolutely positioned boxes that would be positioned after the clamp point would be hidden regardless, whether they are before or after it in the layout tree. What breaks the web are abspos after the clamp point that are positioned to be visible before it. In the current proposed spec text, once the clamp point is determined, knowing whether a box should be hidden is a matter of seeing its position relative to the clamp point in the layout tree. Figuring out where an abspos is positioned with respect to the clamp point is an additional layer of layout complexity that wouldn't be present in the current proposal. The alternative is to never hide an abspos, but in that case authors would still need to specify overflow: hidden.
Slight preference (without having thought too hard in terms of complexity) to never hide absposes whose containing block is not within any of the lines, fwiw.
They do not belong to a "line" other than for purposes of their hypothetical position / paint order...
E.g., I think something like:
<divid=clamp>
... <!-- clamp point is above here --><divstyle="position: absolute">This should paint</div><divstyle="position: relative"><divstyle="position: absolute">This shouldn't</div><divstyle="position: fixed">This probably should?</div></div></div>
Implementation wise would definitely be harder tho, wonder if people have strong opinions one way or the other?
Firefox has been shipping parts of the
continue: collapse
proposal (see #7708 and #10816) in their implementation of-webkit-line-clamp
, which included hiding content after the clamp point. For absolute positioned elements, they would be hidden if they are after the clamp point in the layout tree, regardless of where they are positioned.However, this abspos behavior seems to break the web. Firefox got three different bug reports (bugs 1934547, 1934811 and 1936267), one of which affecting LinkedIn, where an absolutely positioned element that was placed at the end of a line-clamp container (or in an
::after
pseudoelement) but positioned to show before the clamp point was expected to be visible. In two of these three cases, these positioned elements were the "Show more" button that would turn off line-clamping.All of these cases use
-webkit-line-clamp
together withoverflow: hidden
, so absolutely positioned boxes that would be positioned after the clamp point would be hidden regardless, whether they are before or after it in the layout tree. What breaks the web are abspos after the clamp point that are positioned to be visible before it. In the current proposed spec text, once the clamp point is determined, knowing whether a box should be hidden is a matter of seeing its position relative to the clamp point in the layout tree. Figuring out where an abspos is positioned with respect to the clamp point is an additional layer of layout complexity that wouldn't be present in the current proposal. The alternative is to never hide an abspos, but in that case authors would still need to specifyoverflow: hidden
.cc @frivoal @bfgeek @emilio @dholbert
The text was updated successfully, but these errors were encountered: