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

> Don’t you have the same problem with explicit fallbacks as well, if none of the specified fallbacks work? What do you get in that case?

I'm not sure what problem you're referring to. The behavior for fallbacks is well-specified. (Currently it's "just use the final fallback", but there's an open issue to change it to "continue using the last one that worked"; I just couldn't get to it before my vacation.)

> What are they?

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.

> Even that is better than nothing.

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.

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.

(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.)

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

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