# Design Notes > Why Svelte Scoped Props exists as an ecosystem proof before proposing compiler support. **Source:** [https://scoped.svelte.page/docs/design-notes](https://scoped.svelte.page/docs/design-notes) --- Svelte Scoped Props is a proof vehicle. The goal is to test the shape, tradeoffs, and failure modes of `scoped:` in userland before asking the Svelte team to consider anything like it in core. ## TLDR We still believe the child component should own its styling contract. A child should decide which props are class-like, where those props land, and whether a prop named `class` even means CSS. But Svelte works from the parent component's markup and scoped CSS analysis. At the point where we can cheaply rewrite a parent call site, we do not have a reliable child type graph or child prop contract. So the alpha takes the smallest explicit path: ```svelte ``` The parent declares, at the usage site, "this value is one of my scoped CSS classes." The child still decides what to do with the resulting normal prop. There are now two companion artifacts for reviewing the idea: a [live proof page](https://poc-scoped-svelte-page.humanspeak.workers.dev) that shows the cases running, including SSR, and a [Svelte fork PR](https://github.com/humanspeak/svelte/pull/1) that sketches what native compiler support could look like. ## Why Test This Outside Core? An installable package gives us a real place to prove the idea. - We can test literal values, dynamic `ClassValue`s, aliases, spread forwarding, SSR, and CSS pruning against an actual app. - We can find bad edges before proposing language or compiler surface. - We can show screenshots, examples, and failing cases instead of asking maintainers to reason from an abstract issue. - We can learn whether people actually want this syntax before adding weight to Svelte itself. Native compiler support would be cleaner than this package. It would already know the scope hash, could avoid the marker snippet, and could place runtime helpers without a published-package workaround. This package exists to make the case concrete. ## How We Got Here ### Plain component `class` cannot be magical This is the maintainer mantra around this subject, and this package is designed to respect it. In Svelte, `class` on a component is just a prop. A component can use `class` as CSS, as data, or not at all. As a Svelte repo member put it in the `class` attribute discussion, the compiler does not know how a component uses a prop named `class`; it could mean something completely different. Automatically treating every component `class` as a scoped CSS handoff would break that contract. It would also smuggle new language behavior behind a prop name that already belongs to component authors. That is why plain `class` stays plain: ```svelte ``` The caller must opt in: ```svelte ``` #### References - [Svelte issue #9044 comment](https://github.com/sveltejs/svelte/issues/9044#issuecomment-1653301326) - Svelte repo member explanation that `class` on a component is just a component property, so compiler magic based on the prop name would be risky. - [Svelte issue #6972](https://github.com/sveltejs/svelte/issues/6972) - ` ``` The preprocessor can rewrite the prop: ```svelte ``` but the selector still is not attached to a local element in the parent component's markup. Outside core, the package has to preserve the parent selector by adding an uncalled snippet marker. The marker is derived per selector, so a compound rule like `.parent-owned.dimmed` yields a single marker node that carries both classes: ```svelte {#snippet __svelte_scoped_props_marker()} {/snippet} ``` The snippet is never called, so that node never renders. It only gives Svelte's CSS analysis a local class usage to see, which keeps the selector alive and lets Svelte add the correct scope hash. Combinator selectors are mirrored the same way — `.a .b` becomes a nested pair of marker nodes — so compound and combinator scoped rules survive pruning. The nodes are `` rather than typed tags, so the marker is dynamically typed: Svelte's pruner matches it against any element-qualified selector, and it carries no void or content-model constraints. That marker is an implementation scar. Native support would already know that `scoped:class` is intentionally exporting a parent-scoped class through a component prop, so it could preserve the selector directly without the fake snippet. ## What This Alpha Is Trying To Prove - `scoped:` is explicit enough to avoid automatic component `class` magic. - The child remains the owner of where class-like props are applied. - Prop aliases are necessary for real wrapper components. - Dynamic `ClassValue` support matters. - SSR needs the scoped class in the rendered HTML, not after hydration. - Spread forwarding is viable once the parent has already scoped the value. - The language boundary is clear: this works in Svelte markup, not arbitrary objects. ## Current Bet The current bet is that explicit usage-site syntax is the best testable compromise: small enough to ship as an ecosystem package, clear enough to discuss with the team, and honest about the places where native compiler support would do a better job.