Re: [w3ctag/design-reviews] Specification review for CSS Anchor Positioning (Issue #848)

> I'm not sure what problem you're referring to. 

The problem of having popups that are not visible, and are cut off or even cause scrolling.
Currently the API is designed as if repositioning tooltips so they’re still visible is the exception, not the rule, yet most use cases require repositioning.


> When the position you specified is where you want it to be. Not everything wants to move around to stay visible. This is the case for _almost every_ element on the page normally, and there's no particular reason to assume it would be different here.

See, this is exactly why we ask for an explainer which includes user needs and use cases. It’s hard to review something if we're not on the same page about what problem it's solving.
I was thinking the primary use cases are things like popups, popovers, menus etc. But maybe that's not the case? 


> No, it's much worse than nothing if the author's intent was that it's in the exact place it's supposed to be already. Moving it would be confusing and possibly mess up their design. We simply cannot infer what the author's intent was here.

Authors often forget things, or don't debug their design thoroughly. I can easily see authors testing their website on a large viewport on desktop and not considering fallbacks because everything works fine.
I’m not saying authors should not be able to express their intent that their popup should not move. But if -- say -- 90% of use cases require the popup to shift position to be visible, it seems odd that it would be opt-in, rather than opt-out.
So again, it all depends on what the use cases are.

> The author has easy ways to express some common forms of "keep it on-screen if possible" via the `auto` side keyword already. There's discussion on a "sliding" behavior as well that'll probably materialize in the spec as we work out the details and be similarly trivial to apply.

It would be useful to have a more concrete example of what's the minimum code required to express "make sure this is always visible unless it literally doesn't fit".

> (If anything, the fact that there _are_ trivial ways to activate simple fallback without having to use `@position-fallback` means that if you don't use any of the fallback methods, that's a (very weak) signal that you actively don't want fallback at all.)

I disagree, see above.

-------

Another question I had: Looking at the syntax, I cannot quite imagine what the code would look like for a popup that includes a pointer arrow, which is very common for these (especially if it includes position fallbacks). Is it possible, and if so, how? If it's not possible, are there any level 2 plans to facilitate these use cases? 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/848#issuecomment-1644273748
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/848/1644273748@github.com>