- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 17:05:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Anchor Positioning`, and agreed to the following: * `RESOLVED: ED of Anchor Positioning, editor TabAtkins iank_ jhey` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: CSS Anchor Positioning<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7282<br> <fantasai> TabAtkins: presented early idea in May<br> <fantasai> TabAtkins: continued working on it<br> <fantasai> TabAtkins: Jay has prepared a slide deck intro with details<br> <TabAtkins> s/Jay/Jhey/<br> <xfq> https://jhey-presents.netlify.app/tpac-2022/<br> <fantasai> jhey: CSS needs you! So want input on shaping where this goes<br> <fantasai> jhey: anchoring on the Web is a common pattern, very tricky, and headache for developers<br> <fantasai> ... when do I do it, how do I do it?<br> <fantasai> ... How to calculate the position, can I do it in an attriute<br> <fantasai> ... it's used for tooltips, menus, things driven by interaction<br> <fantasai> ... but the most common pattern is pop-ups, things that need to get into the top layer<br> <fantasai> jhey: Thinking of a tooltip, we have a containing viewport, and then we have the anchor thing like a tooltip, and then the anchor which is a button or something<br> <fantasai> ... and then have the arrow visually connecting the two<br> <fantasai> jhey: There are workarounds using abspos, requiring a special DOM structure involving wrappers and relpos<br> <fantasai> ... potential invalid HTML to put things inside other things<br> <fantasai> ... it'shard to scale or respond to viewport changes<br> <fantasai> ... might go with an example like this (shows code example)<br> <fantasai> ... you could go different route without a wrapper, then need to work out positoins<br> <fantasai> ... but it's hard to maintain<br> <fantasai> jhey: could use JS, but then need boilerplate, and styles are leaking into scriptland<br> <fantasai> ... then what info do you need, how to calculate offsets, etc.<br> <fantasai> ... (shows code example)<br> <fantasai> jhey: All of those solutions look the same<br> <fantasai> ... user sees it looks greatn, but dev experience is not great<br> <fantasai> ... done right this could be much better for a11y etc also<br> <fantasai> jhey: There's issues!<br> <fantasai> ... when something goes out of the viewport, if things change, how do we change? what about scrolling?<br> <fantasai> ... Lots of edge cases<br> <fantasai> jhey: Someone solved it?<br> <fantasai> ... there was one called tether.js, another popper.js<br> <fantasai> ... interactions are handled by JS, very config-heavy<br> <fantasai> ... lots of things to decide on, and another dependency to maintain<br> <emilio> q+<br> <fantasai> ... it gets the job done, but devs don't typically like adding extra JS files<br> <fantasai> jhey: Another is Floating UI, less download, but is it better to use, still extra dependency, which to use?<br> <fantasai> jhey: How about we keep the styles in the styles and use a new anchoring API?<br> <fantasai> ... we have container, viewport, tooltip<br> <fantasai> ... think about viewport like ocean, anchor is anchor , and chained to the tooltip<br> <fantasai> ... here the browser is working out hwere to put it. Not enough room for the boat here? shift it down<br> <fantasai> ... no depedencies no wrappers<br> <fantasai> jhey: We're experimenting and learning, I've got some demos here<br> <fantasai> jhey: Basic anchor, this is how it looks<br> <fantasai> ... no DOM structure required, can live anywhere<br> <fantasai> ... here I've got two boats tethered to the same anchro<br> <fantasai> ... I have an anchor name, tether to it<br> <fantasai> ... passing anchor name and use whichever position I want<br> <fantasai> ... I'm using clacl here, can use inside calc<br> <fantasai> ... and then anchor-side will get the width/height of anchor<br> <fantasai> ... browser will work out the offsets as I move things around<br> <fantasai> [What's happening slide]<br> <fantasai> jhey: Containment works as ussual, browser handles offsets for us<br> <fantasai> ... different fallback positions<br> <fantasai> ... if boat can't fit in the ocian here, then move it somewhere else<br> <fantasai> ... UA does it for me<br> <fantasai> ... use position-fallback to attach to fallback list of positions<br> <fantasai> .. can change containment, is contained by viewport or something lower in the tree<br> <fantasai> ... can clip x axis or y axis<br> <fantasai> ... or both<br> <fantasai> ... same demo again where constrained by scroller instead of allowed to leak<br> <fantasai> jhey: Things needed are things liek popups<br> <fantasai> ... being able to anchor things in the top layer<br> <fantasai> ... you can do this currently with JS solutions, but they do hit some limits<br> <fantasai> ... wrt resizing<br> <fantasai> ... Another is <selectmenu><br> <fantasai> jhey: Where this gets really cool, you can do some interesting things<br> <fantasai> ... we have a chart, can use anchor positions in calc() I can tether a tooltip to the chart<br> <heycam> q+<br> <fantasai> ... and attach the min and maximum, and it'll work it out for me<br> <fantasai> ... you can use more than one anchor in your positioning<br> <fantasai> ... or anchor to highest bar or lowest bar<br> <fantasai> ... can also do nested menus, holy grail of anchoring<br> <fantasai> ... just anchor to something inside, and works well, menus squishes as viewport gets narrower<br> <fantasai> jhey: A few open questions<br> <fantasai> ... how to detect which side to put your arrow?<br> <fantasai> ... how do we scope things like position-fallback<br> <fremy> q+<br> <astearns> ack emilio<br> <fantasai> emilio: I had a question, seen a lot of ways of when viewport resizes, most of the fallback is clipping or shrinking<br> <fantasai> emilio: how easily can you do sliding fallback instead?<br> <fantasai> emilio: when container goes out of view<br> <emeyer> q+<br> <fantasai> emilio: thinking about how some native platforms and even Gecko's popups specify after position, and the way we do it, you have an anchor node and you specify the side of the anchor and the side of the popup you want to align<br> <fantasai> emilio: e.g. top left top left, woud put your item on the bottom by default<br> <fantasai> emilio: would give you various ways to figure out the final position if you don't fit<br> <fantasai> emilio: it not be so powerful with offsets, like the fancy chart anchoring was pretty cool and not sure to what extent could do<br> <fantasai> ... but for anchoring to single thing, seems much easier to reason about vs doing all the math and fallbacks yourself<br> <fantasai> ... Have you thought about that kind of API< you can specify where the popup goes relative to anchor?<br> <fantasai> ... we allow customization with margins<br> <fantasai> ... so we use the top/left margin to shift in the direction you're anchored<br> <fantasai> ... so was wondering what kind of exploration you've done of this kind of space and other ways in platform<br> <fantasai> ... what Gecko does is very similar to what ??? does<br> <fremy> q- because I had the same remarks as emilio<br> <fremy> q-<br> <fantasai> ... I don't think Windows has a native thing<br> <fantasai> iank_: We did do a more limited version of this, anchor to a single version<br> <fantasai> ... similar to what you're describing<br> <fantasai> ... we found though that yes, it covers the 60-70% case, but you start to lose out on some of the slightly more advanced cases<br> <fantasai> ... and there are cases, multiple anchoring thing, is quite useful for a number of use cases<br> <fantasai> iank: [missed example]<br> <fantasai> TabAtkins: You might wanto use min/max zero or 100%<br> <fantasai> ... or fallback 0 or 100%<br> <fantasai> ... so you're anchored to the side until anchor goes off the screen<br> <fantasai> ... Right now here with the pop up tersm, it's pretty awkward right now<br> <fantasai> ... Maybe these cases are simple enough to use syntax like you suggested<br> <fantasai> ... but this should be a reasonable case, and not require hundreds of @position-fallback rules, because that's bad<br> <fantasai> [shows content out demo]<br> <fantasai> emilio: In your example where the container shrinks, the positioned elements flips from below to on top of anchor<br> <fantasai> ... but in one example gets clipped instead of remaining in viewport<br> <fantasai> ... inside a container instead of viewport<br> <fantasai> ... if you keep shrinking, it could be kept inside, but then leaks<br> <fantasai> ... by default, authors won't test all combignations, and things will be offscreen in some cases<br> <astearns> zakim, close queue<br> <fantasai> ... so more declarative could allow UA could make sure that the positioning is on-screen<br> <Zakim> ok, astearns, the speaker queue is closed<br> <astearns> q?<br> <fantasai> iank_: any time that we tried to go, "ok, we want this behavior", there's a use case for opposite vehavior<br> <fantasai> ... some cases do actually want it fixed<br> <fantasai> iank_: hear your concern, but there's a plethora of use cases and all of them want something slightly different<br> <fantasai> ... similar argument could be made for testing all possible screen sizes, and yeah you need to test<br> <astearns> ack heycam<br> <fantasai> heycam: Thanks for presentation, a few questions<br> <fantasai> heycam: the pop-up thing, does that always move to the top layer or not required?<br> <fantasai> TabAtkins: not required<br> <fantasai> TabAtkins: if using popup API, moves to top layer<br> <fantasai> ... but otherwise treated as abspos<br> <fantasai> iank_: The containing block, you can only reference anchors within that contianing block<br> <fantasai> ... so useful for components<br> <fantasai> ... so go to the scrolling example, here the contianing block is inside the scroller so it stays inside<br> <fantasai> heycam: One question is what happens when there are transforms between anchored thing and anchored<br> <fantasai> iank_: Similar rules, scrolling is complicated and want to talk about that separately<br> <fantasai> ... but for transforms use staticpos propagation rules, basically assume no transforms<br> <fantasai> heycam: no transforms?<br> <fantasai> emilio: transforms make a containing block for fixed descendants<br> <fantasai> iank_: thing that breaks is if you're transforming the anchor, that does break<br> <fantasai> ... there's a tradeoff here in that this is fundamentally a layout effect<br> <fantasai> ... so animating a transform, don't want to slow it down<br> <fantasai> ... there is an option to incorporate transform<br> <fantasai> heycam: what about shadow tree and visibility of names?<br> <fantasai> ... is this another example of issues around exposing names to shadow trees?<br> <fantasai> TabAtkins: yes<br> <fantasai> ... using anchor name itself isn't problematic, because it's a tree search<br> <fantasai> ... but for the fallback rule and its name, that has the same problems we have in other rules like @keyframes<br> <astearns> ack emeyer<br> <fantasai> emeyer: seems like a lot of the xamples use a lot of calc'ing,<br> <florian> +1 to emeyer<br> <fantasai> ... I wonder if anchor-side keywords in the draft, are those supposed to be ands, can they be ors?<br> <fantasai> ... so you could say somehting liek center left?<br> <fantasai> iank_: A lot of these use left/right, and haven't implemented center<br> <fantasai> ... so many oculd be replaced with left center<br> <fantasai> emeyer: So popup in the middle, wouldn't need calc?<br> <fantasai> jhey: could use percentages<br> <Bert> (For the historians: Around 1997, Håkon and I discussed floats with anchors and ‘elastic bands’, to try and keep floats near their anchors or near each other, depending on the strength of the ‘elastic’. Among the goals were sidenotes and parallel texts, such as a text and its translation. The difficulty for the author to know whether to write "see on the left" or "see on the right" was one reason we decided to postpone that feature.)<br> <fantasai> emeyer: so for simple things might not need calc()<br> <fantasai> emeyer: My other question is, am I understanding that a popup can be placed in relation to multiple anchors?<br> <fantasai> TabAtkins: yes<br> <fantasai> emeyer: so text with footnote reference in the middle, could have the footnote could be vertically center-aligned but have its edge against the column of text<br> <fantasai> TabAtkins: yes<br> <fantasai> emeyer: ok!<br> <fantasai> jhey: [missed]<br> <fantasai> astearns: So little over time<br> <iank_> q?<br> <fantasai> TabAtkins: I'd like to request resolution<br> <fantasai> ... last time was to have a UD, haven't done that yet<br> <fantasai> ... but it seems like to become an ED at this point<br> <fantasai> ... so would like to request an ED of this draft<br> <fantasai> astearns: Any objections?<br> <fantasai> [none]<br> <fantasai> [discussion of editors]<br> <fantasai> RESOLVED: ED of Anchor Positioning, editor TabAtkins iank_ jhey<br> <fantasai> astearns: Please make ED asap so we can file issueS!<br> <fantasai> iank_: I'm free to chat during break<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-1249591201 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 17:05:13 UTC