[css-overflow] Web compat issue when hiding abspos after the line-clamp point

[andreubotella]

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.

cc @frivoal @bfgeek @emilio @dholbert

[emilio]

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:

<div id=clamp>
  ... <!-- clamp point is above here -->
  <div style="position: absolute">This should paint</div>
  <div style="position: relative">
    <div style="position: absolute">This shouldn't</div>
    <div style="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?

[frivoal]

This is unfortunate. Just hiding abspos after the clamp point was simple and convenient. That said, even though we're looking for a different behavior due to compat needs, I don't think we should introduce a difference in behavior between line-clamp under the legacy syntax and under the new one. There are already a few small differences in terms of how you activate the feature, but once it's on, it's on, and I think we should stick to that.

Now, as to what the behavior should be… I'm inclided to suggest keeping it simple, and just letting absolutely positioned elements (maybe even those that are descendents of relpos) be show, without further complication. Most likely, authors doing this will move them back to somewhere they can been seen anyway (like the LinkedIn example of the "show more" button). If authors leave the at their static position, it'll be a little weird, but it's easily rememdied: either move it to somewhere useful, or use overflow hidden.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow] Web compat issue when hiding abspos after the line-clamp point, and agreed to the following:

• RESOLVED: do not skip painting for abs pos where the containing block for the abs pos is at or above the line clamp

The full IRC log of that discussion

<nicole> emilio: I implemented line-clamp model so you don't paint lines that are clamped. Including abs pos if static position is after clamp point
<nicole> emilio: had to revert behavior change, so need a new solution
<nicole> emilio: most sensible, keep painting abs pos whose containing block is at or above the line clamp container
<nicole> emilio: not counting abs pos contained in an inline element
<florian> q+
<nicole> emilio: only abs pos that hang off of clamped container or above
<astearns> q+
<nicole> emilio: could restrict it more, main issue is you still need to dig through arbitrary content to find abs pos elements
<nicole> iank_: you need to do that anyway
<nicole> iank_: abs pos still has geometry
<nicole> emilio: still need to lay it out
<nicole> iank_: yes
<andreubotella> q+
<nicole> emilio: in gecko after layout, build display list, if you don't paint, just keep the subtree
<nicole> emilio: abspos, painting order depends on in flow position
<astearns> ack florian
<nicole> florian: could we not do it, not paint, not bother with complexity. Can't from a webcompat perspective. They use the abs. pos to add a button to expand the clamped area
<nicole> florian: Emilio's proposal is probably the best
<nicole> florian: people may move it and it will pop up out of there. If they put it somewhere reasonable the behavior will be reasonable. If they want to be sure it isn't visible, overflow hidden
<nicole> iank_: relpos can affect the painting
<kizu> q+
<nicole> emilio: the way gecko paints abs pos: traverse layout tree, end up in inflow pos of abs pos, then build display list for the abs pos
<nicole> iank_: oh, we don't do that, I'm not concerned
<nicole> astearns: is this just abs pos or other things too? ex. anchor positioning
<dholbert> (rel-pos and sticky-pos are worth considering too)
<dholbert> (but hopefully can be disregarded)
<kizu> q-
<nicole> TabAtkins: currently have the ability to do that
<astearns> ack astearns
<nicole> astearns: does position relative to anchor make a difference
<nicole> TabAtkins: it is absolutely pos
<nicole> iank_: if potential anchor is past line clamp, we don't consider that a potential anchor
<astearns> ack andreubotella
<nicole> andreubotella: not great to have text that is hidden but not abspos. One option to limit this to ____
<florian> s/____/the -webkit- prefixed version
<florian> q+
<nicole> andreubotella: but would cause a difference in layout between line-clamp and webkit-line-clamp. Not desirable.
<emilio> q+
<nicole> andreubotella: should authors be told to use overflow hidden? We were hoping to avoid this with web components
<andreubotella> s/with web components/with this redefinition of (-webkit-)line-clamp
<nicole> iank_: for the 99% case, this doesn't matter. For the cases with combat challenges, people do want the abs pos to be painted
<nicole> iank_: I think that's fine
<florian> s/combat/compat/
<nicole> iank_: we should minimize differences between webkit-line-clamp and line-clamp for autoprefixer's sake
<astearns> ack florian
<nicole> florian: also thinks this is fine, don't restrict to webkit prefix
<nicole> florian: kind of handy to create button to expand clamp
<astearns> ack emilio
<nicole> florian: in the few cases where people didn't want it to paint authors can use clip and other options
<nicole> emilio: weird if we painted arbitrary abspos. ex. an icon but not a button
<nicole> emilio: in this case you are just affecting something inside the line clamp tree, so it seems like a feature
<nicole> Emilio: proposed resolution, do not skip painting for abs pos where the position is at or above the line clamped container
<nicole> holbert: wants to add mentioning containing block
<florian> s/where the position/where the containing block
<nicole> astearns: edit, do not skip painting for abs pos where the containing block for the abs pos is at or above the line clamp
<nicole> RESOLVED: do not skip painting for abs pos where the containing block for the abs pos is at or above the line clamp

[smfr]

Did this resolution only apply to -webkit-line-clamp, or also to line-clamp?

[andreubotella]

Did this resolution only apply to -webkit-line-clamp, or also to line-clamp?

To both.

[smfr]

Why don't we do the sensible thing for line-clamp, and only this hacky thing for the legacy property?

[emilio]

Not opposed to that, though it'd be ideal if we didn't have a legacy switch.

[bfgeek]

Why don't we do the sensible thing for line-clamp, and only this hacky thing for the legacy property?

It was discussed (see minutes) but in the room preference was to keep everything consistent. (And likely necessary due to auto-prefixers already using line-clamp)

[tabatkins]

Importantly, this seems like a potentially useful behavior, and we dont' want to encourage people to use the old syntax just for that.

[andreubotella]

Would this work the same for position: fixed boxes, except depending on whether the fixed positioning containing block is at or above the line-clamp container? I haven't really thought so far about how fixed positioning would interact with line-clamp.

[andreubotella]

The continue: collapse spec PR (#10816) was updated with this change, and tests for this resolution have been merged in web-platform-tests/wpt#52279. That spec change and those tests cover #11962, but that resolution subsumes the one in the current issue.