-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: better flip
animations
#13317
feat: better flip
animations
#13317
Conversation
🦋 Changeset detectedLatest commit: 180e538 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Looks awesome! |
Marking this ready for review in the meantime, on reflection there's no reason to hold up the improvements in this PR. Aside from the Firefox issue which does seem like a browser bug, I don't think the browsers are at fault here, it's just a super hard problem when you have existing transforms involved. I actually think we might ultimately want a completely different approach that can handle things like rotation and skew, in which case we'd need to compute the effective current transform matrix (including translations caused by layout) and use matrix decomposition to compute a sensible looking path between positions. Probably not a priority for 5.0 though! |
@Rich-Harris can you shine the light on the People just wondering here: https://www.reddit.com/r/sveltejs/comments/1fklm73/curious_about_the_use_of_var_in_the_svelte_5/ |
@tontonsb, as dummdidumm replied on Reddit, it's for performance: |
This throws an error in chromium < 128
because the document.body.parentNode.parentNode === document // true Is that different in Safari? |
Continuation of #13107. I've tried so far in vain to solve the Firefox bugs, and will likely admit defeat since it's a real edge case.
It turns out we can't infer the effective zoom level from
style.width
relative to the bounding client rect, because of CSS transforms. Instead we need to readelement.currentCSSZoom
or — in Safari, which doesn't support it — calculate it manually by walking up the DOM.I did find some other issues relating to existing transforms, which get particularly fun to think about when there are individual
scale
/translate
rules in addition totransform
ones.It may be better to worry about these details later, and at least release the improvements so far...
...but for now I'll leave this here in draft mode.
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint