- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 14:24:53 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> andreubotella: we previously resolved on abspos wrt compat behavior<br> <TabAtkins> andreubotella: in #11379<br> <TabAtkins> andreubotella: we show all abspos whose CB is the line-calmp container or a predecessor<br> <TabAtkins> andreubotella: we never resolved o nwhat to do for abspos whose CB is a descendant of the line-clamp container<br> <TabAtkins> andreubotella: we'd discussed it, just never resolved<br> <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<br> <TabAtkins> andreubotella: and in that, if the CB is in a discarded fragment, the abspos wouldn't show up<br> <TabAtkins> andreubotella: so the behavior i'm ipmlementing is the abspos is hidden if its static position is below the clamp point<br> <TabAtkins> andreubotella: but Ian had a differetn udnerstanding, that an abspos is hidden if and only if its CB is fully below the clamp<br> <TabAtkins> andreubotella: that includes the previous resolution, and is also simpler to implement in chromium<br> <florian> q+<br> <emilio> q+<br> <TabAtkins> andreubotella: it's less similar to continue:discard, but considering we're dealing with webcompat i think it makes sense<br> <astearns> ack florian<br> <TabAtkins> florian: making sure i understand<br> <TabAtkins> florian: in both cases, we're talking only about abspos whose CB is a descendant of the clamp container<br> <TabAtkins> florian: other cases are handled already<br> <TabAtkins> florian: so q is if we hide the abpsos when its CB is after the clamp point, or static position is after<br> <TabAtkins> florian: if CB is after the clamp point, its static position is necessarily after too<br> <TabAtkins> florian: but reverse isn't necessarily true<br> <astearns> ack emilio<br> <TabAtkins> florian: CB might be (partially) above the clamp, but static posiition is after. that's the case, yeah?<br> <TabAtkins> andreubotella: correct<br> <TabAtkins> emilio: if the CB is another abspos that's already out of the question<br> <TabAtkins> emilio: so this is only if the CB is in-flow<br> <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<br> <TabAtkins> emilio: that seems sensible to me<br> <astearns> ack fantasai<br> <iank_> q+<br> <TabAtkins> florian: so in andreu's initial, if the CB was partially in and partially out, but the staticpos was out, you suppress<br> <TabAtkins> florian: but now if the CB is partialy in and partially out, you always paint the abspos<br> <astearns> ack iank_<br> <TabAtkins> fantasai: yeah, don't thinkwe should depend on static position unless it's staically positioned<br> <TabAtkins> iank_: i think we should indeed use this simple thing<br> <TabAtkins> iank_: removing static position is trivial, shoudln't depend on it<br> <TabAtkins> iank_: and anchorpos can depend on entirely differnt things, not caring about static poisition at all. shouldn't try and depend on that<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: thinking about pagination, more interesting<br> <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<br> <TabAtkins> fantasai: so there's an inconsistency in pagination today. hope someday we can fix<br> <iank_> thats not strictly true for chromium's implementation.<br> <TabAtkins> fantasai: but for this case, i think it's reasonable to do a simpler appraoch - if something is discarded<br> <TabAtkins> florian: i think i largely agree, but in pagaintion i'm not clear this behavior is wholely wrong<br> <TabAtkins> florian: moving an abspos back to earlier pages when the CB is paginated should get right<br> <TabAtkins> florian: but if the CB is an inline on a later page, less convicned it's worthwhile to move to an earlier page<br> <TabAtkins> astearns: sounds like we ahve a resolution for this particular case<br> <fantasai> I think drawing outside the fragmentation container is wrong<br> <TabAtkins> andreubotella: proposed: an abspos is hidden if and only if its CB is fully after the clamp point<br> <fantasai> TabAtkins: IIRC, we do have the geometry of everything after the clamp point?<br> <fantasai> andreubotella:<br> <fantasai> andreubotella: yep<br> <fantasai> TabAtkins: So well-defined what the position of things is<br> <fantasai> andreubotella: but I wouldn't be sure that's true for 'continue: discard'<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: An abspos is hidden by line-clamp only if its CB is fully below the clamp point<br> <TabAtkins> andreubotella: should this also apply to fixpos?<br> <TabAtkins> iank_: yeah they're the same<br> <TabAtkins> iank_: if there's a transformed ancestor, it's jsut a normal abspos<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11962#issuecomment-2772735883 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 14:24:54 UTC