CSS Scoping Changes in Svelte 4 Break Parent‑to‑Child Styling

The goal is to decide how to handle the stricter CSS scoping introduced in Svelte 4, which treats plain class names as locally scoped unless explicitly marked with :global, breaking existing parent‑to‑child styling patterns used in many projects and component libraries.

Constraints include the need to maintain visual consistency across a large codebase, the reliance on third‑party Svelte packages that have not yet updated their styles, and the risk of either over‑using :global (which weakens encapsulation) or delaying necessary refactoring. Uncertainty remains about whether the Svelte team will ship a compatibility mode to ease incremental migration.

Will the Svelte team provide a compatibility flag to restore the Svelte 3 scoping behavior? How can teams evaluate the impact of the scoping change on their existing styles without introducing regressions? What migration strategies balance encapsulation safety with the effort required to update third‑party components?