-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Option to disable style encapsulation #5492
Comments
I like the style encapsulation but not the shadow dom for inner custom elements. |
I would appreciate this unrelated to custom elements. I'm (trying to) preprocessing the svelte styles to css-modules so don't need the extra encapsulation. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Closing as duplicate of #6186 (that one is newer, but has more info and ways to use this right now) |
First off, thanks for creating and maintaining Svelte! It is a fantastic framework. 🙂
Summary
TL;DR: I would like an option like
... which does the same thing as
customElement: true
without actually building a custom element. I.e., it would remove thesvelte-*
classes from the DOM rendering and CSS, but do nothing else.Justification
Currently there are several issues with using Svelte in
customElement: true
mode, such as:$destroy()
call can cause memory leaks: ondestroy in custom elements #1152{ target: ..., props: ...}
).Also: the solutions are not obvious. For instance, I would prefer to create the Svelte component in
connectedCallback()
and destroy it indisconnectedCallback()
, but perhaps others have different needs. You could also imagine folks disagreeing on whether to use shadow DOM or light DOM (#1748), closed shadow versus open shadow, or even the emerging declarative shadow DOM standard.Proposal
So here's my pitch: instead of a one-size-fits-all solution for custom elements, what if we separate the concept of style encapsulation and custom elements? Then users could just use the standard Svelte component API to create their own web components. It doesn't actually require much code, as I found through tinkering.
However, this approach isn't really viable because of how CSS is handled. There's no way to create a regular Svelte component without the built-in style encapsulation, i.e. without the
svelte-*
classes. You could write a Rollup plugin to remove thesvelte-*
stuff and attach the CSS toshadowRoot
instead ofdocument.head
, but that gets kinda gnarly. (Or you could just learn to live with the extra unneededsvelte-*
stuff, but I'm a perf guy, so I'm against that. 😁)To be fair, with my proposal, the solution for "components within components" would just be that it's up to the author to make sure that styles are properly encapsulated between the inner and outer components. But I'd argue that this is probably the default case, especially when you're building a standalone web component for third-party consumption.
So this is my proposal. I hope it's interesting at least! 🙂
The text was updated successfully, but these errors were encountered: