Re: [csswg-drafts] [css-position] Ability to set a positioned element's containing block to another element (#5952)

> So I'll start out by saying there is a lot of complexity that the proposed `<popup>` element has avoided by placing in the top layer, e.g. you can snapshot the current (post-transform, post-scroll, etc) position of the "anchor" and position the popup relative to this.

Could you elaborate on what you mean by "placing in the top layer"?

> (I believe that the popup is dismissed when something scrolls etc, which means that you don't need to synchronise this with composited scrolling).

This is unclear. It's not mentioned in the [explainer](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md#light-dismiss) nor in the [Open UI definition of "light dismiss"](https://open-ui.org/components/select#light-dismiss).
Furthermore, since `<popup>` is supposed to be able to emulate things like `<select>`, I don't think it's intended to be dismissed when scrolling.

> @tabatkins & I wrote up some thoughts about something very similar to what @Crissov has just described a few months ago. And while this doesn't solve what `<popup>` is trying to achieve exactly it may still be useful.
> 
> (@tabatkins also has a blog post from 2010? with very similar ideas).
> 
> See here:
> [gist.github.com/bfgeek/60d4f57092eadcda0d4f32a8eb23b4c8](https://gist.github.com/bfgeek/60d4f57092eadcda0d4f32a8eb23b4c8)

Thank you for putting this up, that's a very interesting proposal. 
It's not clear to me what would happen in the (rather common) case of having multiple matches for the same id in the same containing block.
I'd change `anchor`'s grammar to `<ident>+`, so that each element could associate itself with multiple anchors, to potentially "interface" with multiple separate bits of CSS which expect different anchor names.

One issue I see with the anchor declaring itself as an anchor instead of the popup referring to it via a selector is when multiple libraries want to position popups relative to elements in the host page. They can set `anchor` using a selector, but then each library overwrites the `anchor` value the previous libraries have set. Specificity wars ensue for which library will win. The libraries that lost don't get a nice fallback either, just popups randomly positioned (even with the fallback syntax, where would you place them?). There's no nice way to detect this from JS either, you'd need to fetch your intended anchor via JS, read its computed style to see what value the anchor property has, and if you've gone there you may as well just set the popup's style based on that computed style and be done with it.

> The other restrictions are this needs to be "pre-scroll", "pre-transform" similar to how other things in abspos works today. (This is what makes it not immediately useful for the `<popup>` usecase).

Why would that make it not immediately useful for the `<popup>` use case?

> Restricting to an `<ident>` instead of an arbitrary selector, or complex function has nice side effects. But any solution will need to limit to the containing-block subtree.

I think that could be workable, combined with a solution for visually escaping any clipping (discussed separately in #5699).

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5952#issuecomment-777566800 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 11 February 2021 15:16:09 UTC