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?

> There's plenty of reasons to not do a fallback, 

What are they?

> and no reasonable way to predict what fallback would work in an automatic fashion anyway.

The spec [already proposes a simple mechanism for this](https://drafts.csswg.org/css-anchor-position-1/#fallback-rule:~:text=The%20most%20common%20types%20of%20fallback), in a note. Even that is better than nothing.

In the spirit of ["simple things should be easy, complex things should be possible"](https://w3ctag.github.io/design-principles/#simplicity:~:text=%22simple%20things%20should%20be%20simple%2C%20complex%20things%20should%20be%20possible.%22), I think it would be good to have some kind of automatic fallback for the very very common case where authors want to guarantee that the positioned element is always visible (unless that's not physically possible, e.g. it's actually larger than the viewport) and don't care about the specifics much (or care but only to some degree, i.e. this should be combinable with specifying fallbacks explicitly). 

It may even make sense to make this the default (with an opt-out), but that depends on the use cases you collected (and what the reasons are that you mention), as well as the quality of the automatic fallback algorithm. From the outside, it looks like the vast majority of use cases I see would prioritize being always visible vs being displayed in the way specified. 

The current API for fallbacks is **beautiful** for enabling a multitude of possibilities, but it makes the common case fairly involved, and I worry it will result in a lot of popups and tooltips that are out of the viewport a lot of the time, harming user experience for end-users.

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

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