[css-overflow-4] Should abspos painting in line-clamp depend only on whether the containing block is before clamp?

[andreubotella]

When implementing #11379 in Chromium (https://crrev.com/c/6257576), it became clear from @bfgeek's reviews that he and I didn't share the same understanding of how abspos should behave when their containing block is a descendant of the line-clamp container, in the continue: collapse case:

• My understanding was that previously, abspos would be hidden if their position in the box tree is after the clamp point, regardless of what their containing block did; and that with the resolution in [css-overflow] Web compat issue when hiding abspos after the line-clamp point #11379, this would still be the behavior for abspos whose containing block is a descendant of the line-clamp container. This (minus the [css-overflow] Web compat issue when hiding abspos after the line-clamp point #11379 resolution) is the behavior in my spec PR [css-overflow-4] Draft spec for continue: collapse (#7708) #10816, in the experimental Chromium implementation, and in the WPT tests I wrote while working on that implementation. I think it is also the behavior Firefox had before they rolled back not painting content after clamp as a result of the abspos compat issue.
• Ian's understanding was that whether an abspos gets painted depends entirely on whether its containing block starts before the clamp point. This aligns with this comment on the continue: collapse issue.

This affects cases such as the following, where the first abspos would always be painted, but second abspos would be hidden in my understanding and painted in Ian's:

<div style="line-clamp: 3">
  <div style="position: relative">
    <div>
      Line 1 <br>
      Line 2
    </div>
    <div style="position: absolute"></div>
    <div>
      Line 3 <br>
      Line 4
    </div>
    <div style="position: absolute"></div>
  </div>
</div>

I don't think we ever discussed this in the CSSWG (although I think we have discussed some of this in hallway conversations in TPAC or F2F's), and the only thing that came close to this in the various issues and PR's is that comment by @tabatkins about the painting of abspos depending on their containing block, and my WIP PR that has the other behavior. So we should resolve on something.

@emilio @frivoal @alanbaradlay

[emilio]

I would have expected Ian's interpretation fwiw (so all the absposes in there getting painted), but agreed we didn't discuss that.

[emilio]

I think it's the logical / consistent behavior given we decided that:

<div style="line-clamp: 3; position: relative">
    <div>
      Line 1 <br>
      Line 2
    </div>
    <div style="position: absolute"></div>
    <div>
      Line 3 <br>
      Line 4
    </div>
    <div style="position: absolute"></div>
</div>

Should paint both absposes as well, tho.

[bfgeek]

An additional issue with relying on the static-position is the fact that it creates inconsistency with something like: top:0 for example.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-4] Should abspos painting in line-clamp depend only on whether the containing block is before clamp?, and agreed to the following:

• RESOLVED: An abspos is hidden by line-clamp only if its CB is fully below the clamp point

The full IRC log of that discussion

<TabAtkins> andreubotella: we previously resolved on abspos wrt compat behavior
<TabAtkins> andreubotella: in #11379
<TabAtkins> andreubotella: we show all abspos whose CB is the line-calmp container or a predecessor
<TabAtkins> andreubotella: we never resolved o nwhat to do for abspos whose CB is a descendant of the line-clamp container
<TabAtkins> andreubotella: we'd discussed it, just never resolved
<TabAtkins> andreubotella: when i was working on chrome impl, tests, and spec pr, i was trying to get as close to continue:discard as possible
<TabAtkins> andreubotella: and in that, if the CB is in a discarded fragment, the abspos wouldn't show up
<TabAtkins> andreubotella: so the behavior i'm ipmlementing is the abspos is hidden if its static position is below the clamp point
<TabAtkins> andreubotella: but Ian had a differetn udnerstanding, that an abspos is hidden if and only if its CB is fully below the clamp
<TabAtkins> andreubotella: that includes the previous resolution, and is also simpler to implement in chromium
<florian> q+
<emilio> q+
<TabAtkins> andreubotella: it's less similar to continue:discard, but considering we're dealing with webcompat i think it makes sense
<astearns> ack florian
<TabAtkins> florian: making sure i understand
<TabAtkins> florian: in both cases, we're talking only about abspos whose CB is a descendant of the clamp container
<TabAtkins> florian: other cases are handled already
<TabAtkins> florian: so q is if we hide the abpsos when its CB is after the clamp point, or static position is after
<TabAtkins> florian: if CB is after the clamp point, its static position is necessarily after too
<TabAtkins> florian: but reverse isn't necessarily true
<astearns> ack emilio
<TabAtkins> florian: CB might be (partially) above the clamp, but static posiition is after. that's the case, yeah?
<TabAtkins> andreubotella: correct
<TabAtkins> emilio: if the CB is another abspos that's already out of the question
<TabAtkins> emilio: so this is only if the CB is in-flow
<TabAtkins> emilio: if it's in-flow, proposal is that if the in-flow is completely clamped, you don't paint the abspos, otherwise you do
<TabAtkins> emilio: that seems sensible to me
<astearns> ack fantasai
<iank_> q+
<TabAtkins> florian: so in andreu's initial, if the CB was partially in and partially out, but the staticpos was out, you suppress
<TabAtkins> florian: but now if the CB is partialy in and partially out, you always paint the abspos
<astearns> ack iank_
<TabAtkins> fantasai: yeah, don't thinkwe should depend on static position unless it's staically positioned
<TabAtkins> iank_: i think we should indeed use this simple thing
<TabAtkins> iank_: removing static position is trivial, shoudln't depend on it
<TabAtkins> iank_: and anchorpos can depend on entirely differnt things, not caring about static poisition at all. shouldn't try and depend on that
<astearns> ack fantasai
<TabAtkins> fantasai: thinking about pagination, more interesting
<TabAtkins> fantasai: if doing some regions things, abspos containing block on second page with an abspos that positioned itself really far up, impls struggly with that. can't move to a previous page very well, but can push to next page
<TabAtkins> fantasai: so there's an inconsistency in pagination today. hope someday we can fix
<iank_> thats not strictly true for chromium's implementation.
<TabAtkins> fantasai: but for this case, i think it's reasonable to do a simpler appraoch - if something is discarded
<TabAtkins> florian: i think i largely agree, but in pagaintion i'm not clear this behavior is wholely wrong
<TabAtkins> florian: moving an abspos back to earlier pages when the CB is paginated should get right
<TabAtkins> florian: but if the CB is an inline on a later page, less convicned it's worthwhile to move to an earlier page
<TabAtkins> astearns: sounds like we ahve a resolution for this particular case
<fantasai> I think drawing outside the fragmentation container is wrong
<TabAtkins> andreubotella: proposed: an abspos is hidden if and only if its CB is fully after the clamp point
<fantasai> TabAtkins: IIRC, we do have the geometry of everything after the clamp point?
<fantasai> andreubotella:
<fantasai> andreubotella: yep
<fantasai> TabAtkins: So well-defined what the position of things is
<fantasai> andreubotella: but I wouldn't be sure that's true for 'continue: discard'
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: An abspos is hidden by line-clamp only if its CB is fully below the clamp point
<TabAtkins> andreubotella: should this also apply to fixpos?
<TabAtkins> iank_: yeah they're the same
<TabAtkins> iank_: if there's a transformed ancestor, it's jsut a normal abspos

[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.