SvelteKit styling and CSS classes

[sevmonster]

Under Svelte, CSS classes are scoped to the elements they are applied to, and CSS selectors that don't utilize a scoped class are hidden from the build. Controversially, components have no way to signal to Svelte a CSS class is in use, so any selectors using classes passed to a component via a property will not be processed. Not here to debate on that in particular, just looking for answers and providing background.

Recommendations around both Bits-UI and Svelte make it clear the options available:

• Use snippets to replace component content, applying classes to the embedded DOM elements, which brings them in-scope
• Create a custom component and embed and apply classes/styling directly, possibly also using snippets in the case of extending existing components
• Use a utility class framework with extractors that work on components, e.g. Tailwind; since the classes are shared between the project and don't change, it's safe for the tooling to emit global and reusable classes

All the basic examples in Bits-UI documentation seem to expect the latter of the three. Which is fine, but I really don't like the look of huge identical class lists when repeating the same component over and over. I could compartmentalize the utility classes into custom components, but I really don't want to have to basically duplicate a component with no other changes than to apply a preset list of styles, maybe with built-in variants determined by a prop.

So my question is, what's the best way forward here to achieve the most favorable result, given my criteria—simple project structure with no extraneous components or utility class spam? What I'd really like to do is to use utility classes for one-off instances, and make CSS classes to handle the rest, like traditional web development. This may not be very "Sveltey", but I can live with that.

Also, how should I handle out-of-scope components, like portals? They are removed from the flow of the page and parented directly to the body, so styles have to be re-defined for them, and they can't have styles composed under the main component scoped class. How does that fit into all of this? While I think I get why it was done this way, I can't say it isn't annoying.

[rakeshutekar]

The trick is to stop thinking of these as component-scoped styles and lean into global classes for anything you want to reuse — which works cleanly because Bits UI forwards class (and style) straight onto the underlying DOM element via restProps. So a plain global class name lands exactly where you'd put it in hand-written HTML.

Reusable CSS classes without the utility spam

Put the classes you want to reuse in a global stylesheet (app.css, or any non-<style>-block CSS), and just pass them:

<Accordion.Trigger class="accordion-trigger" />

/* app.css — global, so never scoped away, never tree-shaken */
.accordion-trigger { /* ... */ }
.accordion-trigger[data-state="open"] { /* ... */ }

This is exactly the "traditional web dev" model you're after. The reason your instinct to use component-<style> classes fails is the one you already named: Svelte scopes them and prunes selectors it can't see used, and a class handed to a child component is invisible to the parent's scoping. Global CSS has neither problem. You can still keep it organized — one .css file per component/feature, imported once — without wrapping every Bits primitive in a bespoke Svelte component.

Reach for a one-off scoped class only when it's genuinely one-off; for that case either use a utility (class="mt-2") or, if you want a scoped class to apply to a child component's element, use :global() on it:

<Dialog.Overlay class="overlay" />
<style>
  :global(.overlay) { /* applies even though .overlay lands on a child element */ }
</style>

Portals

Portalled content (Dialog/Popover/Tooltip content, etc.) is moved to document.body, so it's outside every component's scope — scoped styles can never reach it. Two working options:

1. Global classes (recommended, same as above): give the content a class and define it in app.css.

   <Dialog.Content class="dialog-content"> ... </Dialog.Content>

   /* app.css */ .dialog-content { /* ... */ }

2. :global() from any component, since the selector isn't scope-bound:

   <style> :global(.dialog-content) { /* ... */ } </style>

Either way the class ends up on the real portalled node (Bits UI forwards it), and because the rule is global it applies regardless of where in the DOM the portal is mounted. So portals aren't a special case in your mental model — they're just the clearest reason the reusable-styling layer needs to be global rather than component-scoped.

Net: global stylesheet for the reusable stuff, class-passthrough to place it, utilities or :global() for genuine one-offs. That gets you the simple structure you want without per-component wrappers and without utility-class walls.

[rakeshutekar]

Fair, and you're right on all three. The parameterless :global {} block is the thing I should have led with instead of the :global() selector. Anchoring it under a scoped class is the clean answer: Svelte keeps .myapp-nav hashed to the component but leaves everything inside the block unscoped, so it compiles down to roughly .myapp-nav.svelte-xyz [data-menubar-trigger]. Scoped container, global descendants, and nothing leaking out to clash elsewhere. That's the both worlds result you were after, and I didn't surface it.

The portal disable and svelte-css-rune are both new to me as well, so thanks for writing up what you actually landed on. Pairing the :global {} block with turning the portal off so the content stays in the component tree is a genuinely tidy combo. Appreciate you circling back with the real solution.

[sevmonster]

I truly appreciate the reply, but I'm having trouble understanding you. Could you add a period after every word so that I can read it better? It would really help me out. Thank you!

[rakeshutekar]

sorry bruh! you do you.

[sevmonster]

The man behind the curtain appears...

Amazing how much more genuine and human you sound in 5 words when you aren't ensloppifying the internet with your agent.

[rakeshutekar]

Lol, used llm to rewrite my answers to make them more well written so you can understand, sorry for being nice enough to use my tokens to make sure you understand the answer.