- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 21:30:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] inset-inline-start: anchor(start) is confusing`, and agreed to the following: * `RESOLVED: No change for now, file an issue to make logical values clearer more generally (e.g. by introducing container-start etc.)` <details><summary>The full IRC log of that discussion</summary> <emilio> fantasai: we have these wm-relative start/end<br> <emilio> ... sometimes these are relative to a separate thing, container vs. element<br> <emilio> ... if you have an arabic select in an english page<br> <emilio> ... how do you want that to layout?<br> <emilio> ... in its container's wm or the anchor's wm<br> <emilio> ... for logical props we did the element's writing-mode<br> <emilio> ... because we don't know the cb at that point<br> <emilio> ... but with alignment we use container's wm<br> <emilio> ... but you say self-start to align in their own direction<br> <emilio> ... anchor pos is interesting because you're using the wm of the anchor box to resolve inset-inline-start<br> <emilio> ... but the anchor(start) gets the start using the WM of the containing block which in most cases is going to be the page itself (e.g. for fixed pos)<br> <emilio> ... so inset-inline-start: anchor(start) gets nonsensical results<br> <emilio> ... because you're anchoring against the wrong edge<br> <emilio> ... this showed up in a demo from argyle<br> <emilio> ... and the position is borked in some cases...<br> <emilio> ... are we setting people up for failure here?<br> <emilio> ... I think we are<br> <emilio> ... and I don't like it<br> <TabAtkins> q+<br> <florian> q+<br> <Rossen> ack TabAtkins<br> <emilio> TabAtkins: while I understand the concern<br> <emilio> ... there is an extremely consistent pattern about what a bare logical keyword refers in various contexts<br> <emilio> ... in anchor pos they have a particular meaning<br> <emilio> ... would be very unfortunate if some properties interpreted bare keywords against one box and others in another<br> <emilio> ... e.g. position-area<br> <emilio> ... would be really unfortunate that position-area and anchor(start) referred to different thign<br> <emilio> ... logical properties are unfortunate<br> <emilio> ... you always get this mismatch with logical values vs. logical properties<br> <emilio> ... so I don't want to change this, I think it happens everywhere<br> <emilio> ... don't want to break this for anchor functions specifically<br> <emilio> ... we might have made a mistake and should've made the logicals were different<br> <oriol> +1<br> <emilio> ... but we're in the world that we area where logical vals refer to cb and self-* refer to your own<br> <Rossen> ack florian<br> <emilio> ... we should stick with that<br> <emilio> florian: are we in a situation where we need to care about three rather than 2?<br> <emilio> ... is the anchor's WM relevant?<br> <emilio> TabAtkins: there are use cases that would like to, but we've avoid adding it until someone bugs us about it enoough<br> <emilio> florian: your argument for consistency makes sense but I don't know it trumps<br> <iank_> `anchor(inside)`/etc solves this<br> <emilio> TabAtkins: the problem is solved, you can use `anchor(self-start)`<br> <emilio> florian: problem needs to be solved *well*<br> <emilio> TabAtkins: want to push back pretty strongly<br> <emilio> ... if there's no missing / un-addressable use case, consistency is a usability concern<br> <emilio> ... teachability / knowledge-transfer are super important, not theoretical purity<br> <emilio> ... so as long as getting it is stupid, and I think using self-start is fine since that's what you need to use in position-area<br> <Rossen> q<br> <emilio> florian: it seems like an author deliberately trying to solve it has the tools<br> <emilio> fantasai: argyle was deliberately trying to solve it and got it wrong<br> <emilio> TabAtkins: I don't see why this doesn't apply to all other cases<br> <emilio> ... if we want to change all of them we can try<br> <emilio> ... but I don't want this to be a one off<br> <emilio> q+<br> <Rossen> ack emilio<br> <fantasai> emilio: I agree with Tab generally. It is very unfortunate though.<br> <fantasai> emilio: If we did at parse-time change anchor-start to container-start or otherwise give them new names that are more explicit<br> <fantasai> emilio: I think it may itigate some of that.<br> <fantasai> emilio: It will show up in devtools, and it'll be more obvious that it's not what you want<br> <fantasai> emilio: I do get confused all the time about what things are relative to<br> <fantasai> emilio: For example float logical values<br> <fantasai> emilio: If this is confusing, and I think we all agree it is.<br> <fantasai> emilio: you try to do the right thing, you do the obivous thing to match 'start' and 'start'<br> <fantasai> emilio: Maybe we can add a better name for the containing block values?<br> <fantasai> TabAtkins: I wouldn't be against that, to ad a cb-foo variant and employ aliasing so that unlabeled one gets transformed<br> <fantasai> TabAtkins: as long as we don't do it for just this spot<br> <emilio> emilio: maybe just `container-start` / `self-start`?<br> <emilio> fantasai: yeah wouldn't do `cb-`<br> <emilio> TabAtkins: so preference close this no change but file a new issue to make this more understandable across CSS<br> <sgill> q+<br> <emilio> Rossen: feels like a big change<br> <Rossen> ack sgill<br> <emilio> emilio: not really, just parse aliases all the way<br> <emilio> sgill: tab you mentioned that we have all these other instances where this is confusing and here we have a scenario where someone was trying to get it right and got it wrong<br> <emilio> ... are there other cases where we have the same issue but it's as hard to get it wrong<br> <emilio> TabAtkins: position-area: inline-start it'd be the container's inline-start<br> <emilio> ... but if your direction is opposite ... same confusion<br> <emilio> ... I don't think this has been a worse problem is that as long as your page is in the same direction the difference doesn't matter, orthogonal stuff is pretty rare<br> <emilio> ... but clear naming of the values is a start<br> <fantasai> emilio: Reason it's so bad in this csae, for anchor-positioning the CB is often the viewport<br> <fantasai> emilio: So not close to your anchor or the element being anchored<br> <fantasai> emilio: And that's what's making it a real problem<br> <fantasai> emilio: Not so common in e.g. flexbox or grid, where items are children<br> <fantasai> emilio: Even if mixed directionality, just aligning things<br> <fantasai> emilio: So anchoring has surfaced this problem in a way that didn't previously<br> <Rossen> ack fantasai<br> <emilio> fantasai: was going to say what emilio said, anchor pos increases the distance between element and containing-bloc<br> <emilio> ... and there might be multiple levels of context changes<br> <emilio> ... previously for alignment we didn't have this issue<br> <emilio> ... where most of the things you're trying to align in the same direction<br> <emilio> ... that's why for alignment we defaulted to using the container<br> <emilio> ... might actually make sense to use the element's direction for abspos alignment<br> <emilio> ... for abspos more generally the alignment is much more about the element<br> <emilio> ... the abpos layout is less container focused<br> <emilio> TabAtkins: that's not true, multiple elements could be anchored positioned<br> <emilio> fantasai: they might be anchored to different things but you are not trying to line them up<br> <emilio> ... not the way you do with items in a list<br> <emilio> ... emilio's idea of creating aliases makes sense<br> <florian> q+<br> <emilio> ... we could also introduce the container-* variants for everything but for abspos<br> <emilio> ... plus abspos has the issue with inset<br> <emilio> ... maybe we should switch the value space keywords for anchor / abspos alignment to not default to cb<br> <emilio> TabAtkins: my fear is that because logical pos are hard to reason about<br> <florian> q-<br> <emilio> ... the less context-specific we need to carry around to know what a value even means the better<br> <emilio> ... so having bare logical keywords for this is valuable<br> <emilio> ... because this is a corner case I don't think it's worth complicating the model as a whole where some starts resolve to self and others to container<br> <emilio> ... since mixed direction is somewhat uncommon<br> <emilio> ... one wrinkle, does the ICB get the the root WM?<br> <emilio> fantasai: yes<br> <emilio> TabAtkins: cool<br> <fantasai> emilio: Some people do writing-mode on body<br> <fantasai> Rossen: We propagate that<br> <emilio> florian: but on <main> you're screwed<br> <emilio> PROPOSED: Close no change, file an issue to make logical values clearer more generally<br> <emilio> fantasai: might want to revisit after the other one, introduce keywords across the world ...<br> <fantasai> PROPOSED: No change for now, file an issue to make logical values clearer more generally (e.g. by introducing container-start etc.)<br> <fantasai> RESOLVED: No change for now, file an issue to make logical values clearer more generally (e.g. by introducing container-start etc.)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13734#issuecomment-4180590549 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 21:30:52 UTC