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

<Pane position='draggable'> should re-parent itself like <Pane position='fixed'> #22

Open
shot-codes opened this issue Jan 2, 2025 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@shot-codes
Copy link

I am adding svelte-tweakpane to svelte 5 project. When I use position draggable then the Pane is not rendered in the DOM at all. Using position fixed works as expected.

The project is here.

In the next couple of days I can try to make a minimal reproduction :)

@kitschpatrol
Copy link
Owner

Hi! Does this still happen if you move <Pane> outside of the Threlte <Canvas>?

@kitschpatrol
Copy link
Owner

kitschpatrol commented Jan 2, 2025

I just confirmed with a quick test that when you put regular DOM elements inside a Threlte <Canvas>, they end up inside an HTML <canvas> element, which treats any children as fallback content.

Using <Pane position='fixed'> or moving the Tweakpane <Pane> outside of the Threlte <Canvas> will fix this for now.

position='fixed' fixed works because that mode uses Tweakpane's default logic to re-parent the pane as a direct child of <body>, while position='inline' and position='draggable' remain inside their original parent element (which in your original case is the HTML <canvas>, which is why it's invisible).

I can see an argument for position='draggable' to behave like position='fixed' and dynamically re-parent itself to <body>. While this could be convenient in certain cases, in some ways the current behavior of position='fixed' is actually less predictable and Svelte-like since it breaks the locality of the <Pane> component in your template code's hierarchy.

I have to think about any unintended consequences of a change here.

Since this isn't technically a bug, I hope you don't mind if I revise the title a bit for clarity.

@kitschpatrol kitschpatrol self-assigned this Jan 2, 2025
@kitschpatrol kitschpatrol added the enhancement New feature or request label Jan 2, 2025
@kitschpatrol kitschpatrol changed the title Position draggable on Pane does not render Pane with position draggable does not re-parent itself like Pane with position fixed Jan 2, 2025
@kitschpatrol kitschpatrol changed the title Pane with position draggable does not re-parent itself like Pane with position fixed Pane with position draggable does not re-parent itself like Pane with position fixed Jan 2, 2025
@kitschpatrol kitschpatrol changed the title Pane with position draggable does not re-parent itself like Pane with position fixed Pane with position='draggable' does not re-parent itself like Pane with position='fixed' Jan 2, 2025
@kitschpatrol kitschpatrol changed the title Pane with position='draggable' does not re-parent itself like Pane with position='fixed' Pane with position='draggable' should re-parent itself like Pane with position='fixed' Jan 2, 2025
@kitschpatrol kitschpatrol changed the title Pane with position='draggable' should re-parent itself like Pane with position='fixed' <Pane position='draggable'> should re-parent itself like <Pane position='fixed'> Jan 2, 2025
@shot-codes
Copy link
Author

shot-codes commented Jan 2, 2025

Don't mind at all. Really appreciate that you looked into it! And happy to hear it was a usage issue :) Works as expected outside the Threlte Canvas :)

@kitschpatrol
Copy link
Owner

kitschpatrol commented Jan 2, 2025

Ok, glad the workaround works for now!

I'll keep this issue open since it is definitely weird that a 'fixed' Pane ends up in a different part of the DOM than 'inline' and 'draggable', and I'd like to make the behavior here consistent one way or the other.

I'm leaning towards changing the behavior of 'fixed' to keep its original location in the DOM, but open to users' thoughts on this. I think it's a tradeoff between being correct / consistent with how elements are expected to stay put in the DOM, vs. being consistent with Vanilla JS Tweakpane and "just working" in slight edge cases like the one you encountered.

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

No branches or pull requests

2 participants