- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 May 2022 16:28:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Anchor Positioning`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Anchor Positioning<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7282<br> <fantasai> ScribeNick: fantasai<br> <fantasai> iank_: Quite a lot of interest in positioning an element relative to another element in the DOM<br> <fantasai> iank_: what we're proposing here isn't a new idea, ppl have had variants of this idea for over 10 years<br> <astearns> explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md<br> <fantasai> iank_: comments on Tab's blog in 2012, etc.<br> <fantasai> iank_: This is basically an extension to absolute and fixed positioning<br> <TabAtkins> s/comments/a post/<br> <fantasai> iank_: in that we can set the inset properties, left/right/top/bottom<br> <fantasai> iank_: and interpret that relative to another element<br> <fantasai> iank_: We've got a prototype of this, and found it to be pretty powerful<br> <fantasai> iank_: you can create popups with this, all sorts of things<br> <TabAtkins> (the old post: https://www.xanthir.com/blog/b48H0)<br> <fantasai> iank_: Tab's written up a basic spec for this, with details of how application works, how this modifies the abspos/fixedpos scheme<br> <fantasai> iank_: and how also the rectangles propagate<br> <fantasai> iank_: couple of interesting point in that one thing we thing is ?? is that when you propagate up the positions of the anchor elements<br> <fantasai> iank_: we think it's should roughly follow the same propagation as static elements, in that it ignores transforms and ???<br> <fantasai> iank_: So that you can still have composited text and not affect layout (?)<br> <fantasai> iank_: I think that's roughly it<br> <fantasai> TabAtkins: There's a limitation on which elements can be targetted with anchor<br> <fantasai> iank_: Roughly speaking, abspos/fixedpos happens right at the end of laying out a container, so you already know where all your in-flow children are<br> <fantasai> iank_: you get some really nice properties if you restrict it to elements within that containing block subtree<br> <fantasai> iank_: [missed]<br> <fantasai> iank_: When we get to abspos/fixedpos positioning, you can reference things that we already know where they are<br> <Rossen_> q+<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> iank_: The other thing is @position-set<br> <TabAtkins> iank_: When you examine the popup/anchor use-cases, necessary ot be able to say "I don't fit in this position, I'd like to try an alternate position"<br> <TabAtkins> iank_: So you might want to be on the right of the anchor, but if there isn't space I"d like to be below, or the left. That's what @position-set is for<br> <TabAtkins> iank_: @position-set lets you specify @try blocks setting top/left etc, and if those don't work (cause overflow) we advance to the next @try and use those instead.<br> <smfr> q+<br> <fantasai> Scribenick: fantasai<br> <fantasai> TabAtkins: [missed]<br> <TabAtkins> TabAtkins: Possibility of exponential epxlosion in layous when you have chained anchors means we want to impose a strict limit on how many @try blocks can be used<br> <fantasai> Rossen_: Generally I'm favorabl to the scenario and the overall approach<br> <fantasai> Rossen_: couple of questions not clear to me, if I heard you right, you said that you can anchor yourself to any other element's box<br> <fantasai> iank_: in the containing block subtree that's already being positioned<br> <fantasai> iank_: abspos/fixedpos has its containing block<br> <fantasai> iank_: anything that has already been positioned within that containing block subtree<br> <astearns> which is an *ancestor* in the containing block subtree<br> <TabAtkins> See https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element for details<br> <fantasai> iank_: so you can't reference something further up the DOM<br> <fantasai> Rossen_: This was exactly my question here<br> <fantasai> Rossen_: and think it's really important in order to prevent some of the really circular dependencies<br> <fantasai> Rossen_: question is still, is the assumption that such element will not contribute to the overall bounds of the containing block<br> <fantasai> iank_: right, this will only apply to abspos/fixedpos elements<br> <fantasai> iank_: so they won't change the containing block size<br> <fantasai> (but presumably would change scrollable overflow area)<br> <fantasai> Rossen_: This feature you describe is almost exactly the feature we proposed called "position: float" or something like that<br> <fantasai> Rossen_: except that you're anchoring to elements, not allowing the rest of the positioning constructs to apply<br> <fantasai> Rossen_: My question was answered, you're basically scoping the anchoring to the containing block, which makes a lot of sense<br> <fantasai> Rossen_: only other question is, you can affect scroll bounds for your containing block still, even for those elements?<br> <fantasai> iank_: yes<br> <fantasai> Rossen_: so behave like normal abspos<br> <fantasai> iank_: yes<br> <fantasai> iank_: You're right that you need to make the scrollbars predictable, but this isn't a new problem<br> <fantasai> Rossen_: not different than if just an abspos<br> <fantasai> Rossen_: last bit, are you scoping only to anchoring, or anchoring plus... can I say anchor me next to the left border + some offset?<br> <fantasai> iank_: These anchor queries you can use in a calculation expression<br> <fantasai> iank_: so you can do calc(this + this)<br> <fantasai> iank_: we had some fun with our happy prototype, where you could do minimum of this anchor's left and this other anchor's left<br> <astearns> ack smfr<br> <fantasai> smfr: Is there potential for circular references?<br> <Rossen_> q-<br> <fantasai> iank_: We want to avoid exactly that<br> <fantasai> iank_: so anchor-positioned things assigned to the same containing block can't reference each other<br> <iank_> https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element<br> <fantasai> iank_: Tab's got all the rules written down in the spec<br> <fantasai> TabAtkins: very certain not a problem<br> <dholbert> q+<br> <chrishtr> Anchoring can only apply *down* the containing block chain, which makes it clear that there are no cycles.<br> <fantasai> smfr: because constrained to something in the containing block, if authors want a global ability they'd have to anchor ...?<br> <fantasai> iank_: have to use fixedpos or something like that<br> <fantasai> TabAtkins: No need to reparent, because fixedpos containing block is the ICB<br> <fantasai> smfr: ...<br> <fantasai> iank_: But then there's things where you want it to work more locally<br> <fantasai> iank_: There's also a proposal which is related to adjusting the scroll position<br> <fantasai> iank_: but that's separate from this<br> <astearns> ack dholbert<br> <fantasai> dholbert: I was wondering, seems like it's ID-based right now, I wonder if that could be ... how do you imagine using this if you want to have multiple in a single page?<br> <fantasai> TabAtkins: where are you seeing this?<br> <fantasai> dholbert: looking at explainer<br> <fantasai> TabAtkins: Ah, MS explainer is earlier draft<br> <fantasai> TabAtkins: look at this spec<br> <fantasai> TabAtkins: we use the anchor-name property, look for the first thing in tree space with that name<br> <astearns> ah, I only read the explainer - not the spec yet :)<br> <fantasai> dholbert: okay<br> <fantasai> iank_: We've got some flexibility in how we do that<br> <fantasai> iank_: I personally like anchor-name solution<br> <fantasai> iank_: requirement is reference things within this containing block subtree<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: Whatever scoping rules we use here we should be consistent with scroll animations, which has a similar named attachment method<br> <fantasai> (and vice versa, they're both early proposals so we switch to whatevers' the best method for both)<br> <fantasai> astearns: Suggest to adopt the spec and fiddle with details in the spec<br> <fantasai> iank_: if anyone wants to play with the prototype lmk<br> <fantasai> TabAtkins: We anticipate asking for ED soon-ish, not just yet<br> <fantasai> TabAtkins: so keep informed<br> <fantasai> s/adopt/read/<br> <fantasai> astearns: I assume there'll be some discussion in your personal repo for awhile, but if significant changes or questions raised, migth be good to update the issue we have on introducing this<br> <fantasai> astearns: so ppl can follow along without following your repo<br> <fantasai> TabAtkins: happy to track issues in both repos<br> <fantasai> TabAtkins: and move issues later<br> <fantasai> fantasai: Why not move it now?<br> <fantasai> TabAtkins: no particular reason<br> <TabAtkins> The scoping rules for anchor-name are just "the subtree that is allowed to contribute an anchor due to the positioning rules", which may or may not match up with what scroll animations exactly want<br> <TabAtkins> ScribeNick: TabAtkins<br> <fantasai> faceless: better to move now then, your private repo isn't backed up by W3C<br> <fantasai> s/faceless/fantasai/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7282#issuecomment-1137506735 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 May 2022 16:28:22 UTC