Skip to content
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

Merged
merged 7 commits into from
Sep 19, 2024
Merged

feat: better flip animations #13317

merged 7 commits into from
Sep 19, 2024

Conversation

Rich-Harris
Copy link
Member

@Rich-Harris Rich-Harris commented Sep 19, 2024

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 read element.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 to transform 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

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • Prefix your PR title with feat:, fix:, chore:, or docs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests and linting

  • Run the tests with pnpm test and lint the project with pnpm lint

Copy link

changeset-bot bot commented Sep 19, 2024

🦋 Changeset detected

Latest commit: 180e538

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
svelte Patch

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

@etainad008
Copy link
Contributor

Looks awesome!
I will try and investigate about the "other issues". Seems mainly like a big mess of browser behavior.

@Rich-Harris Rich-Harris marked this pull request as ready for review September 19, 2024 11:26
@Rich-Harris
Copy link
Member Author

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 Rich-Harris merged commit 321e3ea into main Sep 19, 2024
9 checks passed
@Rich-Harris Rich-Harris deleted the better-flip branch September 19, 2024 14:00
@tontonsb
Copy link

@Rich-Harris can you shine the light on the var vs const change? Is it an optimization, a bugfix or something else?

People just wondering here: https://www.reddit.com/r/sveltejs/comments/1fklm73/curious_about_the_use_of_var_in_the_svelte_5/

@7nik
Copy link

7nik commented Sep 20, 2024

@tontonsb, as dummdidumm replied on Reddit, it's for performance: var doesn't have TDZ, which isn't free. OrdinaryRedditor also has a good reply there.

@PatrickG
Copy link
Member

PatrickG commented Sep 20, 2024

This throws an error in chromium < 128

Uncaught TypeError: Failed to execute 'getComputedStyle' on 'Window': parameter 1 is not of type 'Element'.

because the parentNode of the <html> element is the document itself.

document.body.parentNode.parentNode === document // true

Is that different in Safari?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants