Support native css scoped, at-rule @scope

[alkorlos]

Describe the problem

Chrome has supported @scope since last year, Safari released on the fourth march this year supports @scope, Firefox comming. Soon all browser engines will support native css scoped.

Svelte scoped CSS in this way:

Adding a class to affected elements, which is based on a hash of the component styles (e.g. svelte-123xyz).

To disable this behavior can by adding :global to each class or by installing a library like svelte-preprocess and adding a global attribute to each style tag. These options are not convenient.

Need the ability to disable Svelte scoped CSS globally.

Describe the proposed solution

Add the option scopedStyle: boolean to svelte.config.js to disable Svelte scoped styles.

Importance

would make my life easier

[Rich-Harris]

Now that our parser supports nested CSS natively, we plan to add the ability to do this:

<style>
  :global {
    .foo {
      /* unscoped `.foo` (equivalent to today's `:global(.foo) {...}` */
    }
  }

  div :global {
    .foo {
      /* scoped `div`, unscoped `.foo` (equivalent to today's `div :global(.foo) {...}` */
    }
  }
</style>

This gives you the freedom to write global CSS however you like, including @scope if you so choose.

We won't be adding an option to disable scoped CSS globally. We may use @scope internally instead of classnames once it is supported widely enough.

[TKDev7]

We won't be adding an option to disable scoped CSS globally.

What is the reasoning for this?

[alkorlos]

@Rich-Harris First of all, thank you for the great tool and your work.

Global CSS with @scope in Svelte will look like this:

<style>
  :global {
    @scope (.foo) {
        :scope {
            /* unscoped `.foo` (equivalent to today's `:global(.foo) {...}` */
        }

        /* remaining selectors*/
    }
  }
</style>

This is better than :global(.foo), but it adds an additional level of nesting, which is inconvenient.

We won't be adding an option to disable scoped CSS globally

Global CSS the way it worked over 20 years ago and continues to work today in all browsers, is well-known to all developers, and they are prepared for such behavior. The ability to restore native behavior would be convenient.

From #901:

If <style scoped> was something people opted in to, a lot of people wouldn't use it, and as a consequence they'd end up reverting to over-engineered namespacing conventions (which defeats the object) or they'd experience annoying-to-debug conflicts. Or perhaps they would read about what scoped entails, and opt in reluctantly because they believe it would have deleterious performance impacts. Eliminating that kind of 'configuration anxiety' from web development (and the associated learning overhead) is one of Svelte's goals.

In my opinion, it's strange to change the browser behavior by default, at the same time, the reasons for doing so are also clear. However, in the case of @scoped, the inability to disable Svelte scoped globaly will only add an unnecessary level of nesting in the styles.

[Rich-Harris]

If you want to write CSS without Svelte transforming it, do so in a .css file.

[alkorlos]

Single-File Components format is more convenient than a separate .css file.

[Rich-Harris]

The CSS you're describing isn't related to any component. By definition, it's global. So it makes sense that those styles should live outside a component file.

I'm sorry that you clearly feel differently but there is no world in which it makes sense to add an option for this. It would be horribly confusing, and there is no need for it because you can already do what you want, and it will be easier still when we ship :global {...}.

[Rich-Harris]

I've opened #10815 to track :global {...}, so I'll close this issue

[Rich-Harris]

What is the reasoning for this?

@MrHBS for posterity: the reasoning is that it's a very bad idea. As a component author, you need to understand the effect of the code that you're writing. If this component...

<p>hello</p>

<style>
  p {
    color: red;
  }
</style>

...behaves totally differently based on a configuration option that is set in a different file, and which I may not even control (if I'm writing a library component), then people are just going to end up with buggy apps. We made this mistake previously with a global immutable option, but luckily no-one really uses that. We definitely don't want to repeat that mistake.

[alkorlos]

As a component author, you need to understand the effect of the code that you're writing. If this component behaves totally differently based on a configuration option that is set in a different file, and which I may not even control (if I'm writing a library component), then people are just going to end up with buggy apps.

Fully agree with this. Now it's clear why this issue cannot be resolved.

Still think that even the appearance of this code indicates that there is a problem:

<style>
  :global {
    @scope (.foo) {
        :scope {
            /* unscoped `.foo` (equivalent to today's `:global(.foo) {...}` */
        }

        /* remaining selectors*/
    }
  }
</style>

But adding the option scopedStyle: boolean to svelte.config.js would be even worse.

I don't see a good solution, hope it will be found later.

@Rich-Harris Thank you for the explanation!