- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 21:07:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] allow anchor() within shape()`, and agreed to the following:
* `RESOLVED: Work on this, details TBD`
<details><summary>The full IRC log of that discussion</summary>
<emilio> TabAtkins: authors want to refer to anchors within `shape()`<br>
<emilio> ... anchor resolves to horizontal / vertical offset<br>
<lea> q?<br>
<emilio> ... anchor conceptually makes sense for offsets<br>
<emilio> ... not sure about impl perspective<br>
<lea> q+<br>
<emilio> ... that's my big question, is this something we could allow?<br>
<emilio> ... there are good use cases for it here<br>
<Rossen> ack lea<br>
<emilio> lea: agreed there are good use cases but I thought it was per-property<br>
<iank_> q+<br>
<emilio> ... it's mostly to avoid cycles right?<br>
<kizu> q+<br>
<emilio> TabAtkins: there needs to be a particular context where things are allowed<br>
<emilio> ... there needs to be some context<br>
<emilio> fantasai: I think tab is saying that it's not a size<br>
<dshin-moz> q+<br>
<emilio> ... but length fundamentally is a size<br>
<emilio> ... but anchor computes as a position with respect to another<br>
<emilio> ... most things that take lengths<br>
<emilio> ... can't deal with it, anchor() computes to the same thing on left and right<br>
<emilio> ... to different things<br>
<Rossen> ack iank_<br>
<emilio> TabAtkins: it works here because xy are offsets from the area<br>
<emilio> iank_: are there shape values without the origin?<br>
<emilio> TabAtkins: this would only be for x/y<br>
<emilio> ... it wouldn't be allowed in the relative commands in the shape() syntax<br>
<emilio> ... but would be allowed in the abs commands<br>
<emilio> ... because those are using lengths as a size rather than origin<br>
<Rossen> ack dshin-moz<br>
<dshin-moz> I will just type the question<br>
<smfr> something something the shape will change<br>
<smfr> q+<br>
<dshin-moz> So if the anchor is a scroll compensated, the shape will change?<br>
<emilio> TabAtkins: I think it would, should denote the same point as something anchoring to the same value<br>
<emilio> q+<br>
<Rossen> ack kizu<br>
<kizu> I am trying to unmute<br>
<iank_> i think this depends a lot on the property shape() is used in.<br>
<iank_> e.g. shape-outside should likely just reject as thats only for floating.<br>
<emilio> kizu: +1 to the ask<br>
<emilio> ... for anything where we know offsets of the coordinates we should be able to use anchor()<br>
<emilio> ... this is the case, background-{size,position} could be the case, maybe some transforms though less obvious<br>
<emilio> ... but yeah +1, people have to do weird things<br>
<Rossen> ack smfr<br>
<emilio> smfr: I commented in the issue<br>
<emilio> ... the classic thing would be a speech bubble<br>
<lea> The kinds of hacks authors do today due to these types of limitations… https://frontendmasters.com/blog/perfectly-pointed-tooltips-a-foundation/<br>
<emilio> ... but when that moves around you're going to need a different corner<br>
<emilio> TabAtkins: yeah those would need fallbacks<br>
<emilio> kizu: some things authors do would be to manually check, but if you know the element is always on the right...<br>
<emilio> ... if you have some text box or so ...<br>
<emilio> ... with a background and an avatar and you want a bg to wrap around both<br>
<emilio> ... so you want to draw a shape around them<br>
<emilio> ... so you could use anchor pos for this<br>
<Rossen> q?<br>
<Rossen> ack emilio<br>
<fantasai> emilio: What properties accept shape()? shape-outside would be annoying<br>
<fantasai> iank_: It doesn't make sense on shape-outside<br>
<fantasai> TabAtkins: border-shape would be the cool thing<br>
<smfr> clip-path<br>
<fantasai> TabAtkins: I'm happy if the answer to this is "let's work on the issues". Don't need to resolve on anything here.<br>
<fantasai> TabAtkins: But also if we want to classify paint-time vs layout-time that seems reasonable to me<br>
<fantasai> +1<br>
<fantasai> emilio: Other annoying bit, some of the SVG path commands it gets tricky because exposed to SVG OM<br>
<fantasai> TabAtkins: I wouldn't add it to d-string. Just shape() function.<br>
<Rossen> ack emilio<br>
<Rossen> ack fantasai<br>
<emilio> fantasai: mostly what tab said, restricting it to paint time ops makes sense<br>
<emilio> ... we probably want to get separate coordinates<br>
<emilio> TabAtkins: anchor only provides one direction<br>
<emilio> fantasai: we could consider a shorthand to specify the direction<br>
<emilio> ... but the point of making it conditional on the fallback position is a general problem<br>
<fantasai> emilio: Weren't there proposals for container queries?<br>
<fantasai> emilio: but you can't style the element itself.<br>
<emilio> Rossen: are we going down to fix these around?<br>
<emilio> fantasai: I think we can figure out the details in the issue<br>
<emilio> PROPOSED: Work on this, details TBD<br>
<fantasai> fantasai: wanted to gauge interest and see if any major concerns<br>
<emilio> RESOLVED: Work on this, details TBD<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13716#issuecomment-4180481300 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:07:24 UTC