- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 17:58:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position] Allow a positioned el's containing block to be the anchor`, and agreed to the following:
* `ACTION: Tab and fantasai to reread these minutes and come up with a proposal`
* `RESOLVED: Not allowing to refer to CB by anchor name. We'll address use cases by other means (see minutes for ideas).`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> TabAtkins: When I was on a podcast with Miriam, question of why can't an anchor element anchor to its own containing block.<br>
<fantasai> TabAtkins: Indeed it doesn't make a lot of sense. you could for example anchor it to another abspos that's anchored to the containing block.<br>
<fantasai> TabAtkins: Podcast host filed issue for us.<br>
<fantasai> TabAtkins: Ian pointed out that you don't need anchor positioning in order to position relative to containing block, that's how positioning currently works<br>
<kizu> q+<br>
<fantasai> TabAtkins: Doing so would potentially limit what you can do in some cases when you've got a container that's nested inside itself<br>
<fantasai> fantasai: ????<br>
<fantasai> TabAtkins: ian pointed out usability issues.<br>
<fantasai> TabAtkins: So I suggest we close no change. You don't need anchorpos to do this.<br>
<fantasai> TabAtkins: Someone asked if that limits what you can do with position-try<br>
<fantasai> TabAtkins: but that doesn't require using anchor positioning<br>
<astearns> ack kizu<br>
<fantasai> kizu: I don't understand the argument about useful cases<br>
<iank_> q+<br>
<fantasai> kizu: My thinking generally was that, even though yes you can use just top: 0; to attach to your CB<br>
<fantasai> kizu: didn't make sense that you can't use an anchor name<br>
<fantasai> kizu: So you are limited by this, you cannot use anchor() to target it .<br>
<fantasai> kizu: In my mind you should be able to do this<br>
<fantasai> kizu: Case where inside you have element with the same name... I don't see a use case where I would want this<br>
<fantasai> TabAtkins: The name of your CB is just, you spell it without the anchor() function at all. It can be addressed more simply. Means same as what you would get from anchor()<br>
<fantasai> kizu: I've cases where I susbtitute dynamically the name with stuff<br>
<fantasai> kizu: e.g. :hover { assign name }<br>
<fantasai> kizu: Wrapper breaks this<br>
<fantasai> TabAtkins: In that case, you can hack around it with a dummy abspos<br>
<fantasai> kizu: I think I saw this in some other cases, like link to ??<br>
<fantasai> kizu: People playing with anchor pos stumble on this limitation and wonder why they can't<br>
<fantasai> kizu: It's common to run into it<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: it also means you can't use position-area syntax or the combination fo that and anchor-center<br>
<TabAtkins> fantasai: i think it's weird to exclude it<br>
<TabAtkins> fantasai: i don't want to close this unless there's a good reason not to<br>
<astearns> ack iank_<br>
<fantasai> iank_: I have good reasons why you can't do this.<br>
<fantasai> iank_: On the surface this seems reasonable.<br>
<fantasai> iank_: Part of the issue is that devtooling for abspos should show what the actual CB of an element is. Currently they don't, which creates lots of confusion about scoping.<br>
<fantasai> iank_: A simple thing that browsers can do is show the IMCB<br>
<fantasai> iank_: so devtooling needs to improve substantially<br>
<fantasai> iank_: In no particular order<br>
<fantasai> iank_: The problem with using position-area with this is that the available size is always going to be zero<br>
<fantasai> iank_: E.g. position-try-options doesn't work as you might expect, for example.<br>
<fantasai> iank_: Part of this is also, when you are applying scroll adjustment or scroll filter<br>
<fantasai> iank_: that currently happens within the CB<br>
<kizu> q+<br>
<fantasai> iank_: So it doens't actually work<br>
<bkardell> s/doens't/doesn't<br>
<TabAtkins> (whereas anchoring to a a dummy abspos with `inset:0` does "work" - it scroll like any other content<br>
<fantasai> iank_: Next reason is, it's got poor interaction if CB itself is a scroller<br>
<fantasai> iank_: In that particular case, you might say "I want this to be right of the CB", but it's within the scrollable area. Doesn't do what you want.<br>
<fantasai> iank_: We had previously talked about mode switch so that your CB rectangle would be the scrollable area<br>
<fantasai> iank_: If we do that, then your position wouldn't make sense<br>
<fantasai> iank_: Couple more reasons...<br>
<fantasai> iank_: The component example, anchoring something to a component<br>
<fantasai> iank_: put in issue. Would break this, and require wrapper elements for what I think will be a common use case.<br>
<fantasai> iank_: I could understand an argument for adding convenience functions to reference CB edges<br>
<fantasai> iank_: but I don't think we should do this, will have bad side effects<br>
<fantasai> TabAtkins: On that note, syntax of anchor() and position-area definitely has space for predefined keywords that whatever we want. We could put container as a keyword<br>
<fantasai> iank_: Part of ask here is, you want to be able to select what CB is laying you out<br>
<fantasai> iank_: You provide some CB name on a CB, and then your abspos will skip up to the CB that matches its name<br>
<TabAtkins> agree fwiw. (but definitely a seaprate issue)<br>
<fantasai> iank_: this would solve a lot of problems where people are applying 'position: relative'<br>
<astearns> ack kizu<br>
<fantasai> We already resolved to add that, didn't we?<br>
<fantasai> kizu: ...<br>
<fantasai> kizu: I think for ?? it might be useful.<br>
<kizu> https://github.com/w3c/csswg-drafts/issues/2406<br>
<fantasai> kizu: For scroller-based, I think a better fix could be is the ??? pseudo-element that oriol proposed<br>
<fantasai> kizu: I also agree that maybe having something like a named CB could be nice<br>
<TabAtkins> yeah, being able to distinguish inside-scroller from outside-scroller is pretty important to do eventually<br>
<fantasai> kizu: but my main argument is just that, we have at least 3 cases where authors stumbled across this when using anchor positoining<br>
<fantasai> astearns: I confess, I didn't follow the argument that said the available space will always be zero. But if that's the case, Roman, would the cases where ppl tripped over this, would it even be useful for them even if it worked?<br>
<TabAtkins> (if the CB *is* the anchor, then position-area's grid is degenerate; the center cell fills the entire grid<br>
<TabAtkins> )<br>
<fantasai> kizu: The available space question is only relevant for cases where you use position-try<br>
<fantasai> kizu: ...<br>
<fantasai> kizu: Not sure if you could use 100% as a substitute for anchor-size()<br>
<fantasai> iank_: percentages resolve against the CB<br>
<fantasai> kizu: but you couldn't cross axis<br>
<fantasai> kizu: With anchor-size() you can do calculations based on both axes<br>
<fantasai> iank_: if that's desired, we can add syntax for it<br>
<fantasai> TabAtkins: In that case will want different ones for inside / outside scrollers<br>
<fantasai> kizu: But definitely need devtools to help authors<br>
<fantasai> iank_: 100% agree. I've been advocating to any devtools ppl that will listen that abspos needs help from devtools<br>
<fantasai> iank_: I'm happy to explain what would be useful<br>
<fantasai> [discussion about what to do with this discussion and the various duplicats]<br>
<fantasai> astearns: So proposed resolution is we intend to allow you to target the container with a keyword?<br>
<fantasai> TabAtkins: but keep not referring by name<br>
<fantasai> fantasai: How does that solve the problem?<br>
<TabAtkins> like `anchor(container)`<br>
<TabAtkins> like `anchor(container top)`<br>
<iank_> `anchor-size(container width)`<br>
<fantasai> fantasai: not sure I understand<br>
<fantasai> astearns: All sorts of things go wrong, but only if you refer to it by name?<br>
<fantasai> TabAtkins: Keyword fixes one thing that's wrong. other things are still just as wrong.<br>
<fantasai> TabAtkins: but ability to refer to scrollable area vs ... need keywords to refer to these things<br>
<fantasai> TabAtkins: Right now no way to refer to scrollabe area of an anchor<br>
<iank_> `anchor(container-scroll bottom)<br>
<fantasai> TabAtkins: but for container, might want either one<br>
<iank_> `anchor(container-scroll bottom)`<br>
<fantasai> astearns: Is it reasonable to ask for a named ocntainer?<br>
<fantasai> TabAtkins: yes, I want to think about those two together<br>
<TabAtkins> fantasai: so we already have a resolution to add position-container<br>
<TabAtkins> fantasai: that lets you change CB explicitly<br>
<TabAtkins> TabAtkins: it's a little funky<br>
<TabAtkins> fantasai: it sounds like we need that too<br>
<TabAtkins> fantasai: you probably want a function, not a keyword, so you can pass parameters, like in/out of scrollers<br>
<TabAtkins> TabAtkins: i want to do that for named anchor too, so it should just be a bag of keywords<br>
<TabAtkins> fantasai: so it sounds like we're not addressing this issue in the way it's request, but there are several features that will address the use-case which we want to add<br>
<TabAtkins> fantasai: so closing this as no change for now, investigate keywords/fucntions for referencing the container, and edit in the work for position-container<br>
<fantasai> s/the container/container scrollport vs scrollable area of container/<br>
<fantasai> TabAtkins: We were talking about narrowing the CB. This is about expanding the CB. maybe address by same property.<br>
<TabAtkins> (re: position-container)<br>
<astearns> q?<br>
<fantasai> ACTION: Tab and fantasai to reread these minutes and come up with a proposal<br>
<fantasai> PROPOSED: Not allowing to refer to CB by anchor name<br>
<fantasai> RESOLVED: Not allowing to refer to CB by anchor name. We'll address use cases by other means (see minutes for ideas).<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11769#issuecomment-2776545248 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 17:58:25 UTC