transition:slide looks different (buggy) on Safari

[palask]

Describe the bug
I am using transition:slide in order to slide in a div element after the user presses the button with the arrow pointing down. With Chrome and Firefox on Windows it looks perfect, however on Safari (iPadOS) the inner contents overlap with the button during the transition. Or to be more precise, the inner elements of #lookupAreaContent do not follow the behavior of #lookupAreaContent itself.

To Reproduce
Simplified version:

<div>
	{#if v_lookupArea}
	<div id="lookupAreaContent" transition:slide>
		<div>
			<a href="https://www.google.com" target="_blank">test 1.</a>
		</div>
		<div>
			<a href="https://www.google.com" target="_blank">test 2.</a>
		</div>
		<div>
			<i>add_circle</i>
		</div>
	</div>
	{/if}
	<i on:click={toggleLookupArea}>expand_more</i>
</div>

<script>
import { slide } from "svelte/transition";
let v_lookupArea = false;

function toggleLookupArea(e) {
	v_lookupArea = !v_lookupArea;
}
</script>

Expected behavior
Here is what it looks like on Chrome: https://streamable.com/crvf1n
And here is the buggy Safari behavior: https://streamable.com/ldb1gh

Information about your Svelte project:

• Your browser and the version: Chrome 81 (correct), Safari (broken)

• Your operating system: Windows 10 (correct), iPadOS 13.4.1 (broken)

• Svelte version (Please check you can reproduce the issue with the latest release!): 3.20.1

• Whether your project uses Webpack or Rollup: Rollup

Severity
It is just a design flaw, nothing major.

[antony]

@palask would it be possible for you to create a REPL for this (I tried copy pasting your code but the styles are missing) so that we can reproduce this ourselves please?

[palask]

@antony Here you go: https://svelte.dev/repl/f0a579625c9f4d69978e3e87911a5ac9?version=3.21.0
This simplified REPL still does not include all of the styles from the original project, but even there you can see the inner contents just fading out (and not sliding away) at the end on Safari: https://streamable.com/a5h6od

[kjj6198]

Another way I found it useful to do this on safari (without adding css property) is don't use built-in slide function with transition directive in Safari since it uses css animation. Safari has a bug that it'll ignore element overflow: hidden when element is transitioning.
In this demo I used slide function and change css property directly each frame, which might not be a good idea because it requires you to understand how the internal function works and require JavaScript to do more but at least it solves the issue on Safari.

demo

[benschac]

Added a small fix, I'm having a little trouble setting up my local (in the linked issue). Going to try again tomorrow.

[caroso1222]

As mentioned earlier, Safari won't recognize overflow: hidden in keyframe animations. Adding node.style.overflow = 'hidden' in the bundle (in function create_rule) makes it work. I wonder, before opening a PR, would that be an acceptable approach to solve it? Are we open to add (and subsequently remove) other styles at runtime other than animation?

overflow: hidden is present in all the frames of the slide animation so it'd be equivalent to just set it as a style in the node.

[chmelevskij]

Following @caroso1222 solution, it seems to be working with custom action as well.

I'm using something like:

<script>
  import { slide } from "svelte/transition";
  function safariWorkaround(node) {
    if(navigator.appVersion.includes('Safari')) {
      node.style.overflow = 'hidden';
    }
  }
</script>

{#if open}
  <div transition:slide use:safariWorkaround>
{/if}

But like mentioned in the comment here #5168 (comment) it's probably best to undo that style once transition is done. In my case it's fine

[benschac]

It looks like this isn't an issue any longer. I just opened the test REPL in Safari and I'm on longer seeing the bug in the video linked above in the original post.

[volstas]

The issue reappears in svelte5, can test it here

https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAE62SwU7DMAyGXyWEC0hoFRy7rtLElTcgqAqp01lLkyhxN1DVdyfZCoVx4cDNf2x_-vU7I9doIPLyeeRW9sBLvvWe33F691nEAxiCpKMbgsovVYuHWlhB4zVqdmiMc_vBbwPIKb_mNsN2I_jSeHSWwJLgjIK0EQmdLaPBFk6g89JcJiHZLoBOhB2Rj2VRHI_HVedcZ2ClXJ8xMnRAaaJ5NdLuBa8JIrH7VVXIT2SxMP8J__AnPNaybRuFQRmoCvw1v1RjgfqcGTJnlUG134zkumTkaQm1hjcvbdv0Lsy8L4KtogroKdXYexeIjewUK5uYDq5nYr5fseQu-FpYA_TjcmzDtDQR1hmqB6vyJLu0cgO3bMx-L1avvuuEmLLF2Vn6Ob1rUSO0vKQwwPQyfQDUVmVydAIAAA==

[shadow-identity]

To me, it is reproducible on stable Safari, but works perfectly on Technology Preview Release 203 (Safari 18.0, WebKit 20620.1.6)

[trueadm]

This is a well known bug in Safari around its Web Animations API. Thankfully they fixed it in later versions, that's why the newer versions work. Not sure that's anything we can do about this for older versions though – Safari really needs to move away from pinning releases on OS versions.