- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Mar 2024 15:28:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries`, and agreed to the following: * `RESOLVED: Undo the previous resolution - anchor names are not blocked by any form of containment. But they *are* blocked from escaping a "skipped content" element.` * `RESOLVED: And if a positioned element is "relevant to the user", any element it's anchoring to remains "relevant to the user" as well.` <details><summary>The full IRC log of that discussion</summary> <chrishtr> miriam: right now CQ relies on on side effects from anchor positioning, because anchor names are contained by style containment<br> <chrishtr> miriam: this will also likely cause a problem for other areas such as names for scroll-driven animations<br> <chrishtr> miriam: developers will be frustrated if one stops the other from working<br> <TabAtkins> chrishtr: Proposed resolution (from the issue) is undo the previous resolution, and have anchor-names no longer be contained by style or layout or size<br> <TabAtkins> chrishtr: So that anchor positioning and CQs can work well together<br> <TabAtkins> chrishtr: However, we still need skipped subtrees (from c-v: auto) to block those anchor names<br> <vmpstr> auto or hidden, presumably<br> <TabAtkins> chrishtr: Because when such content is offscreen and skipped, we want the UA to be able to skip rendering entirely, which rquires not doing the layout necessary to position the anchor<br> <TabAtkins> chrishtr: That's fine because the content is offscreen anyway, so anchoring to is isn't useful.<br> <miriam> q+<br> <Rossen_> ack miriam<br> <chrishtr> miriam: wonder if layout containment is also an issue<br> <kizu> q+<br> <emilio> q+<br> <TabAtkins> chrishtr: My proposed res also has it escape layout containment, which I think addresses your concern<br> <Rossen_> ack kizu<br> <TabAtkins> kizu: Some of the cases we'll be fixed by popover in the top layer, it'll escape containment<br> <TabAtkins> kizu: But I think escaping via fixpos escape<br> <TabAtkins> TabAtkins: It's just that anchor names escape, not the positioned element<br> <TabAtkins> kizu: Okay, I thought there were other cases talked about in the thread, but if it's just anchor names that's okay<br> <TabAtkins> chrishtr: Right<br> <TabAtkins> miriam: But my issue is if an element inside a container is able to position relative to an element outside the container; that violates layout containment of the container for the abspos<br> <Rossen_> q?<br> <TabAtkins> chrishtr: Yes, it would be contained.<br> <TabAtkins> emilio: I misunderstood Chris about whether this affects layout containment<br> <TabAtkins> emilio: I'm confused - would the anchoring work?<br> <TabAtkins> emilio: wouldn't this mean you can't anchor anything outside your CB chain, right?<br> <TabAtkins> emilio: And if you hit a fixpos CB that prevents you from going further up, right?<br> <Rossen_> ack emilio<br> <TabAtkins> chrishtr: The case we're addressing is an element outside the CQ beinga ble to anchor to something inside the CQ<br> <TabAtkins> iank_: Right, it's not an OOF inside the subtree beigna ble to escape, it's about being able to anchor to something inside the container<br> <TabAtkins> emilio: Okay, yeah, I was talkinga bout the ohter way, with the positioned element inside the container<br> <miriam> q+<br> <kizu> q+<br> <TabAtkins> TabAtkins: Remember that top layer pulls it out of the tree, and you can move it further up.<br> <TabAtkins> q+<br> <khush> q+<br> <Rossen_> ack miriam<br> <TabAtkins> miriam: I don't think youc an always move it futher up the tree. I want to see if we can solve that half of the problem,t oo.<br> <TabAtkins> miriam: Containers created a fixpos CB is, as far as I can see, always a footgun, it's not something people want from containers.<br> <TabAtkins> miriam: So if we can remove that limitation from CQs that would be excellent<br> <TabAtkins> kizu: For the second part, an element inside a container and you want to position it outside without the top layer, the only thing I can think of is position-container, which lets you position to a different block<br> <Rossen_> ack kizu<br> <Rossen_> ack TabAtkins<br> <chrishtr> TabAtkins: position container can't be used, because it uses the same scoping as anchor names<br> <chrishtr> TabAtkins: for the same reasons that the restrictions are applied in the first place<br> <chrishtr> TabAtkins: and changing that would amount to the same thing as pulling something up in the tree, which is a separate feature possibility<br> <chrishtr> TabAtkins: the top layer is the best solution for all this<br> <chrishtr> TabAtkinss: if we want some other more general thing we can solve it in the position spec<br> <chrishtr> TabAtkins: propose we not try to solve that problem here<br> <Rossen_> ack khush<br> <chrishtr> khush: responding to comment about anchor being on screen causing the anchored element being relevant to the user<br> <chrishtr> khush: not sure how to implement that<br> <chrishtr> vmpstr: if on screen and scrolled offscreen, wont' stop being relevant<br> <chrishtr> TabAtkins: there'd be a hysteresis<br> <chrishtr> khushal: right, would need to bring an offscreen thing back to the screen for it to take effefct<br> <vmpstr> q+<br> <Rossen_> ack vmpstr<br> <chrishtr> vmpstr: minor clarification. Chris mentioned c-v: auto, but shouldn't we include hidden?><br> <chrishtr> chrishtr: agreed<br> <chrishtr> chrishtr: hidden should be skipped<br> <chrishtr> TabAtkins: this falls out of the definition of skipped<br> <TabAtkins> <TabAtkins> chrishtr: Proposed resolution (from the issue) is undo the previous resolution, and have anchor-names no longer be contained by style or layout or size<br> <TabAtkins> 08:08 <TabAtkins> chrishtr: So that anchor positioning and CQs can work well together<br> <TabAtkins> 08:08 <TabAtkins> chrishtr: However, we still need skipped subtrees (from c-v: auto) to block those anchor names<br> <TabAtkins> chrishtr: A little more precisely, a positioned element can anchor to something in a contained subtree, but not the opposite<br> <TabAtkins> TabAtkins: That's handled by just saying the anchor names arent' contained<br> <TabAtkins> RESOLVED: Undo the previous resolution - anchor names are not blocked by any form of containment. But they *are* blocked from escaping a "skipped content" element.<br> <TabAtkins> RESOLVED: And if a positioned element is "relevant to the user", any element it's anchoring to remains "relevant to the user" as well.<br> <Rossen_> github-bot topic: https://github.com/w3c/csswg-drafts/issues/9149<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10040#issuecomment-2009840674 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 March 2024 15:28:33 UTC