Ability to disable css scope across entire application

[bmlyon]

Is your feature request related to a problem? Please describe.

Problem: Svelte does not provide sufficient flexibility when implementing CSS. For example, the ability for scoped components to modify styles related to other components or to modify component scope.

Describe the solution you'd like

Since I am unaware of a way to accomplish this using existing Svelte methods, I would like a way to disable Svelte's CSS scoping application-wide. The ability to disable scoping would allow me to custom implement scoping either on my own or via third party plugins.

Describe alternatives you've considered

• Ability to specify scope via attribute
• Let scoped components modify CSS of other components

Neither of these features are unique and both exist in competing frameworks.

How important is this feature to you?

I cannot use Svelte, either in legacy applications or new ones, until I have a way for scoped components to modify the CSS of other scoped components.

[Conduitry]

You can already do this by wrapping all selectors in :global(...), and there exist PostCSS preprocessors that will take a <style global>...</style> block and wrap each selector in it in :global(...) for you. In general, using global CSS everywhere is something we want to steer people away from, and doesn't feel like something we want to natively make easy or tacitly endorse.

[dreitzner]

@bmlyon

There are multiple ways to achieve what you are describing:

• use css outside of components (or global works too, but in my opinion components holding global styles makes things tricky in bigger projects)
• you can always pass global css classes as props to child components, up with a event callbacks or context
• with the use of the cascade from css and the other possibility from above I don't see any use case that can not be dealt with. If you have a use case that you currently can not accomplish through svelte, please add a short description with possibly a repl to the ticket.

[bmlyon]

• Use of global is not scalable on large projects.
• Having those who write styles request engineering assistance to create props and callbacks is not scalable.

I give up, it seems nobody is willing to listen. At this point it's become clear I can't use Svelte in my projects. I'll move on to a different framework. Sorry to bother y'all, thanks for fielding the questions.

If you could point me at the part of the svelte code responsible for the CSS scoping so I could create a monkey patch for my own use that would be great, but otherwise I've given up hope.

[dreitzner]

@bmlyon

• I agree that :global() does not scale well. This was my argument as well.
• if I understand you correctly (by reading the referenced issues) you what to separate your css from the components. I'd suggest something like having your separate scss setup, with something like BEM or atomic css... Through that you are free of scoped styles.
• abusing scoped components for unscoped styles seems like an antipatter to me, but maybe I do not understand your requirements correctly.
• you can take a look at Allow to customize the css scope class via compilerOptions.scopeClass method #4377 if you are interested in the current proposal of exposing the css class generation as a compiler option

[PaHell]

You can already do this by wrapping all selectors in :global(...), and there exist PostCSS preprocessors that will take a <style global>...</style> block and wrap each selector in it in :global(...) for you. In general, using global CSS everywhere is something we want to steer people away from, and doesn't feel like something we want to natively make easy or tacitly endorse.

For example, I have an Component named Icon with a root element .icon
Styling this element from a parent component using .root > .icon seems impossible without setting the css global.
I dont want to sync classes down to a simple icon component, if a css-only approach is possible, neither I want to wrap some things global, others dont.

[yadoga]

Would like to see something like :local(...) as a complementary method to :global(...).

:local(...) in the sense of "use on self and propagate to descending components only".

I'm currently building a rather large application with SvelteKit. Can confirm it's becoming just a tad bit cumbersome to micro manage alternating sources of truth for certain styles.

As of now I need to equip certain elements with additional classes to be able to address them from a centralized CSS/SASS file. Would love to have more of a cleaner Svelte way available for local / descending styles.

[telamon]

Ran into the the same thing here when attempted to style a child component from a parent please reconsider adding option to disable CSS scoping project wide / rollup.config.js:

  plugins: [
    svelte({
      compilerOptions: {
        dontMangleStyles: true
      }
    }),

Yes i get it that having global css in components is scary for many of us, but steering people towards an ideology is just as bad.

I strongly suggest that svelte should take a neutral stance to this design choice, as products are going to run into scaling issues regardless if they choose scoped or global styling, no solution just tradeoffs.
Sure you can attempt to provide-an over-engineered approach such as the :global() and :scoped() meta-selectors but in it's ultimate form you will have just created something that works equally crappy for both parties and eventually unify both schools through the "svelte bad, framework-X good" consensus.
(<style global></style> is also bad)

This ticket documents a real scaling issue for framework adoption and growth, please reopen 🙏