- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Nov 2023 10:56:04 +0000
- To: public-css-archive@w3.org
In my opinion, this issue (and others, e.g. https://github.com/w3c/csswg-drafts/issues/9149) shows that the current path we're on with fallbacks being applied at used-value time just isn't workable. Spec: > This implies that the values can’t be transitioned in the usual fashion, since transitions key off of computed values and we’re past that point. However, popovers sliding between positions is a common effect in UI libs. Probably should introduce a smooth keyword to [position-fallback](https://drafts.csswg.org/css-anchor-position-1/#propdef-position-fallback) to trigger automatic "animation" of the fallback’d properties. Inventing totally new animation concepts in an attempt to fix the problems from doing the wrong thing doesn't seem worth it at all. (Although I realize that part of the spec doesn't necessarily represent very refined thought on this issue). If we can't make this integrate reasonably with existing CSS, I'd rather drop the feature completely. --- Re. the CQ model: > This is feasible since we require that the anchor element must be laid out before the target element. So the target element can't via its fallback-style affect the layout of the anchor element, nor affect any other layout that would cause a different fallback-style to be chosen? (I guess that would cause problems with the current impl. too). I assume this approach has _some_ associated difficulty? (Otherwise why aren't we just doing it? :slightly_smiling_face:). @bfgeek (since @xiaochengh is OOO). -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8372#issuecomment-1790505145 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 November 2023 10:56:06 UTC