- From: Melanie Richards via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Feb 2021 23:37:19 +0000
- To: public-css-archive@w3.org
Hey everyone, joining the party a little late here, not sure how I missed this thread until very recently. (cc @BoCupp-Microsoft @dandclark @ipopescu93, who I refer to here as "we") For the [`<popup>` proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md) referenced in Lea's original post, our intent here was to use the `anchor` attribute as a marker/hook for a to-be-proposed, CSS-based anchored positioning scheme. How the `popup` (and other similar top-layer elements, future or otherwise) is positioned according to the anchor relationship would be handled in CSS. Note: we're heard "anchor" could be a little overloaded, so this is definitely bikesheddable terminology. Original concepts we fleshed out created a net-new positioning scheme (`position: anchor`), with `anchor-point` (where on the button is a popup anchored to?) and `anchored-origin` (what point on the popup gets anchored to the button?) properties. There were also some `*-adjust` properties the author could use to express how the anchored element (popup) should be repositioned when there is insufficient space in the layout viewport. However, it's better to see what we can reuse in the platform, and we ended up setting that initial design in favor of using an absolutely positioned scheme, with an `anchor()` function used in existent positioning/box sizing properties. Here's a gist that captures some of this early thinking, not yet fully fleshed out into an explainer (text is in flux so please pardon any rough edges, heh): https://gist.github.com/melanierichards/42ffc11f18fd9c69e9bc9cfcc86f39cb You'll notice it's very similar to what @bfgeek and @tabatkins shared. This direction was very much influenced by their ideas, so full props to them and their prior thinking in this space. :) We think it's important that the anchor element is specified via markup or script instead of referenced in CSS, as these identifiers could be dynamic and unknown to the author as they are writing their styles. Two items we haven't be able to solve yet with this direction are: * Can we emit JavaScript events (or provide a pseudo selector) when an anchored element is repositioned? This would help authors who have directionally-aware decorations on their anchored element, such as a pointer arrow on some teaching UI. Some interesting challenges here with having to wait until layout is done to understand how something was repositioned, but maybe you want to do something that impacts layout... * On MacOS, select listboxes are anchored to their button part according to the currently-selected option. In our previous designs, we solved this providing a `delegate` value on the `anchored-origin` property, which would tell the anchored element to delegate its positioning to a descendent (the checked option itself would then have the `anchored-origin` property declared). This is perhaps a more advanced use case and might be best left to script instead of CSS. Example below:  Sounds like there's a lot of interest in this topic, a few different ideas floating around, and some valid concerns about perf and such. What would best help the group explore anchored positioning on the web? Is this worthy of a breakout discussion? -- GitHub Notification of comment by melanierichards Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5952#issuecomment-786304907 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 25 February 2021 23:37:21 UTC