Change removal of unused CSS to just a warning

[EskelCz]

Describe the problem

My case: Imagine you import a component from a 3rd party module (custom Select for example) and want to style it contextually (for example setting width for just one component/page) using classes within that component and the author didn't expose the particular value as a css variable. You are out of luck.

You either have to fork the module to add the variable, or add a global id just so you can target it in a global stylesheet, which is not the place you will look for the value at a later time. Either option is not developer friendly.

There are multiple github issues and stackoverflow questions about how to get around this, so there is clearly demand. I feel like this is a case where Svelte might be too opinionated.

Am I missing something? What is the case for the purge being mandatory?

Describe the proposed solution

The purging of "unused CSS" should be just a warning, or svelte should provide a configuration option to change the default behaviour.

Alternatives considered

Considered polluting the global css (by using :global). Not an option for anyone who uses Svelte to achieve a well organised code.

Importance

i cannot use svelte without it

[Conduitry]

As mentioned in #1594 and #5804, you can make part of CSS selectors global without making the whole selector global, which lets you reach into third-party components and style them only in certain contexts.

Keeping the unused CSS in place in this case would not help, because the selectors would still be getting augmented with this component's .svelte-abc123 class, which would not be present on any elements in the third-party component. This, in general, is the reason why requests to "just don't remove the CSS" have been closed - it's because they will only match elements that Svelte created as part of their component, because the CSS has that component's unique scoping class added, which only elements that Svelte knows about in the component will have.

[Conduitry]

Put another way: if, for example, Svelte could see the <ul> elements in a component but could not see the <li> elements that exist in a child component, then there's nothing helpful that

ul li {
  color: red;
}

could be made to compile to other than exactly what

ul :global(li) {
  color: red;
}

already compiles to.

[EskelCz]

@Conduitry Thanks for a quick response and trying to explain the reasoning. I think I'm fairly well versed in CSS and this still doesn't make much sense to me, so please bear with me a little longer.

From your example, if the local style ul li {} compiles to .svelte-abc123 ul li {}, I don't see the issue with li being a child component which Svelte doesn't see. The browser does and that's what matters in the end, for rendering, is that not so?

My issue with the workaround is that it's not clear/intuitive what it really does.

1. It looks like a CSS pseudo selector, which it's not.
2. The syntax makes it look like the ul is local and li is global, which doesn't make sense to me within a single selector.
3. How can something even be partially global? :) Either it's scoped to the component's class or it's not, right?

[EskelCz]

And of course the workaround doesn't work as needed, what should be contained within a component overrides another. Just tested it.

[rkyoku]

The proposed workarounds for this bug (see #5804 , which was censored) are not elegant, at all.

To circumvent this bug, I have to write a full external LESS file.

There have been multiple outcry about this, and even despite the massive upvotes from users, and despite this being a common scenario, nothing was even heard on the developer's side (going as far as censoring further comments)

I thought that such projects were made FOR the users, and that listening to users was a top priority, but it seems I might have been wrong about that.

Well, I will keep using an external stylesheet... 🤷‍♀️