- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 19:00:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-3] Sticky position and margins (should margins be considered at all?).`, and agreed to the following: * `RESOLVED: Don't consider margins in sticky-pos calculations` <details><summary>The full IRC log of that discussion</summary> <fantasai> iank_: I was looking into sticky positioning optimizations<br> <fantasai> iank_: noticed that margins were a little bit weird, quirky, in implementations<br> <fantasai> iank_: so wanted to ask what was the original intention with margins, and should we change it<br> <fantasai> iank_: currently today there are 3 rectangles we care about<br> <fantasai> iank_: 1. scroll container<br> <fantasai> iank_: 2. sticky view rectangle (which is usually the parent of the stickypos rectangle)<br> <fantasai> iank_: 3. stickypos element itself<br> <fantasai> iank_: Most of the stickypos calculations don't use margin box, they use border box of stickypos element<br> <fantasai> iank_: e.g. you scroll to the top, sticks the border box<br> <fantasai> iank_: this seems desirable<br> <fantasai> iank_: where margins come in is they don't affect stickypos eleent itself<br> <fantasai> iank_: it affects sticky view rectangle, reduces by the margins<br> <fantasai> iank_: it has some unfortunate effects<br> <fantasai> iank_: margins are used for positioning<br> <fantasai> iank_: so e.g. if using auto margins, stickypos no longer works for that element<br> <fantasai> iank_: also if you set margins, it may not go all the wya down to stickypos rectangle when using for positioning<br> <fantasai> iank_: Comments? Thoughts?<br> <Rossen_> q?<br> <fantasai> iank_: atm, Blink and WebKit would ignored auto margins (treat as zero)<br> <fantasai> iank_: so only Firefox is affected by that part<br> <fantasai> emilio: so blink and webkit are already doing what you want to propose?<br> <fantasai> iank_: what I think might be better is to ignore margins completely from stickypos calculations<br> <fantasai> iank_: from examples I've seen online, no one is using margins for the sticky pos rectangle interaction<br> <fantasai> iank_: if we do want to keep margins around, there's a question about how auto vs fixed should work<br> <fantasai> iank_: blink and webkit have other issues, e.g. uses margins that don't exist (e.g. on table cells)<br> <fantasai> flackr: also don't respect margin collapsing<br> <fantasai> flackr: if we use margins, we should use margin collapsing<br> <fantasai> flackr: weird if switching to position:sticky made margins act differently<br> <TabAtkins> fantasai: breaking this down, i think we can def take a resolution that auto margins are 0 for stickypos<br> <Rossen_> ack fantasai<br> <flackr> sgtm<br> <TabAtkins> fantasai: are there any objections to that? it not we can just resolve that and move to the rest of th esubissues<br> <TabAtkins> smfr: so my original thoughts for sticky is that when it's not constrainted by the scroller it behaves identical to relpos<br> <TabAtkins> iank_: it doesn't<br> <TabAtkins> smfr: so only when it's being affected by scrolling are we doing a different margin behavior?<br> <TabAtkins> iank_: yes<br> <TabAtkins> (i think i misscribed what ian's "it doesn't" was responding to)<br> <TabAtkins> iank_: and we're happy to see if this is web compatible<br> <TabAtkins> fantasai: so we think there's a question of what do auto margins do, i think we all agree it should be treated as zero<br> <TabAtkins> fantasai: then another question of whether margins should be used at all for stickypos positioning<br> <TabAtkins> fantasai: and if we continue to honor the margins, do we use collapsed or not<br> <TabAtkins> fantasai: And I think the right answer for that is to use the boxs own margins and descendants but not siblings/parents<br> <TabAtkins> iank_: I'd prefer to avoid the complexity of amrgin collapsing entirely, we don't store enough info for block-start of our boxes<br> <TabAtkins> iank_: So my pref i sto ignore margins completely<br> <TabAtkins> q+<br> <emilio> q+<br> <TabAtkins> fantasai: I think it's reaosnble if you're doing margins to use only the element's own margins<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: given the constraint, which is correct, that in absence of doing stickypos should act like relpos,<br> <fantasai> TabAtkins: margins should work, collapse, etc.<br> <fantasai> TabAtkins: If you scroll slightly, don't want to jump<br> <fantasai> TabAtkins: don't want to change behavior of margins at that point<br> <fantasai> TabAtkins: only reasonable behavior is to either do complicated partial collapsing<br> <fantasai> TabAtkins: or don't care about margins at all<br> <fantasai> TabAtkins: only use the border box<br> <fantasai> TabAtkins: that's consistent with how we choose margin-box vs border-box<br> <fantasai> TabAtkins: when complicated margins we use border-box, because that's the only reasonable thing to do<br> <fantasai> TabAtkins: stickypos shifting is solely on whether border box is escaping or not<br> <Rossen_> ack emilio<br> <fantasai> emilio: does that change negative margins on sticky element? because that seems like a reasonable thing to do<br> <fantasai> emilio: I'm ok trying this, but... I'm a bit concerned<br> <fantasai> emilio: if you're willing to test compat, sure<br> <fantasai> iank_: when I play with examples, I don't see people using margins<br> <emilio> fantasai: If we're gonna honor margins I don't think you want to honor collapsing margins<br> <emilio> ... you want to honor just the element's own margins<br> <emilio> ... and if the element's own margins collapse with the parents then you treat that as zero<br> <emilio> iank_: impl wise I don't particularly want to do that<br> <emilio> ... can of worms<br> <emilio> TabAtkins: if you were collapsing a margin and you're sufficiently close to the top of the scroller<br> <emilio> fantasai: it's not about the scroller, it's about the CB and the viewport<br> <emilio> ... in that case you're adding to your margins<br> <emilio> ... but if you want margins and they collapse you zero-them out<br> <fantasai> e.g. if the element has 3px margin, use that to define spacing between containing block edge and the stickpos<br> <emilio> ... anything we do with margins that ignore clearance it's going to impose a change from sticky to relpos<br> <emilio> ... I'd rather not do that<br> <emilio> iank_: fwiw for other scroll related features they use the scroll-margin<br> <TabAtkins> (the "anything we do" and following line is me, not fantasai)<br> <flackr> My demo in https://github.com/w3c/csswg-drafts/issues/9052#issuecomment-1639234115 shows a margin from the CB<br> <emilio> fantasai: I think this means that if you want spacing among things but not when sticky you need to use padding<br> <emilio> ... and margin won't work anymore<br> <emilio> TabAtkins: yeah, that's right<br> <emilio> fantasai: we should be pretty clear about that implication<br> <fantasai> s/spacing among things but not when sticky/spacing between a stickypos and its containing block even while it's shifting around by scrolling/<br> <flackr> q+<br> <emilio> iank_: I think folks are using margin-trim... ??? (missed)<br> <astearns> ack fantasai<br> <emilio> ... I could see the interaction if we used the margin box of the sticky pos but this weird mixed model is weird<br> <Rossen_> ack flackr<br> <emilio> flackr: I think that the way it behaves right now is conflating margin in two different contexts, the relpos layout is collapsing margin but the sticky margin is wrt the containing block<br> <emilio> ... I'd rather have the zero interpretation, having these two interpretations is awkward<br> <emilio> PROPOSED: Don't consider margins in sticky-pos calculations<br> <emilio> RESOLVED: Don't consider margins in sticky-pos calculations<br> <emilio> <br type=lunch><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9052#issuecomment-1642600755 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 19:00:27 UTC