Scoped styles for <svelte:element>

[sherifsalah]

Describe the problem

Currenlty scoped styling for any dynamic tags generated with svelte:element give the generic warning "Unused CSS selector", not really sure if that's a bug or it should be added as a feature!

Describe the proposed solution

add support for scoped styles with svelte:element

Alternatives considered

currently the only solution to fix that problem is using global styles

Importance

would make my life easier

[baseballyama]

Could you provide us REPL?
I tried to reproduce it on REPL but I couldn't.
https://svelte.dev/repl/7e4c14c9a5ce430488e8bdc331a27976?version=3.47.0

[SarcevicAntonio]

The issue is, that can't use the generic tag selectors like this:
https://svelte.dev/repl/23d982fc6f4f4f06a6aa227860fa2d84?version=3.47.0

Your workaround with using classes works for me right now tho :D

[baseballyama]

Ah I got it. Thank you!

I think this workaround also useful.
https://svelte.dev/repl/3832a541ea24479581c97bfd0a934b7b?version=3.47.0

[tanhauhau]

I guess when we try to see if the selectors match any element, we can make svelte:element to match all element selector ?

<div>
  <svelte:element class="a" this={...}>
     <span />
  </svelte:element>
</div>

<style>
   /* used selectors */
   h1 { }
   p span { }
   ul.a { }
   div > b > span { }
   div > i { }

   /* unused selectors */
   h2 div { }
   h3.b { }
</style>

[baseballyama]

I think the compiler disable CSS removal process if using dynamic class name.
Should we do a similar process for <svelte:element>?
(If <svelte:element> is there, we don't remove css which specified tag name like h1 { color: blue })

[baseballyama]

@tanhauhau

oops, we are posting at the exact same time lol.
Yes, I think we can implement such a process.

Can I try?

[gtm-nayan]

A thought,
Making special considerations for things like svelte:element might get out of hand as more features are added.

How about introducing a way for users to tell the compiler to not purge certain selectors? Essentially what people do with :global() but it'd still keep scoping. This would solve the problem at hand right? While also unlocking more possibilities in userland. An example possibility

There's already an issue proposing something similar, will link it and carry over the discussion there.

[sherifsalah]

A thought, Making special considerations for things like svelte:element might get out of hand as more features are added.

How about introducing a way for users to tell the compiler to not purge certain selectors? Essentially what people do with :global() but it'd still keep scoping. This would solve the problem at hand right? While also unlocking more possibilities in userland. An example possibility

There's already an issue proposing something similar, will link it and carry over the discussion there.

I love this idea, maybe making a special keyword like :global() something like :keep() or whatever will fix all the issues of purging what the compiler sees unused css

[baseballyama]

There's already an issue proposing something similar, will link it and carry over the discussion there.

Could you please tell me where is that?

And personally, it sounds like it is transferring the responsibilities of the Svelte compiler to userland regarding purging CSS.
It seems to me that as long as Svelte has the ability to purge CSS, it has the responsibility to handle all cases.

[SarcevicAntonio]

I'd also love to opt out of purging (while keeping scoping).

[gtm-nayan]

Found it #5804

And personally, it sounds like it is transferring the responsibilities of the Svelte compiler to userland regarding purging CSS.

It is kinda, (technically it'd be the responsibility of not purging CSS), IMO it's fine in this case, we can't expect Svelte to bend for every possible scenario that people can conjure.

Forgive me if I misunderstood the current proposed solution to this issue, my interpretation was that if the component has a dynamic class name somewhere then Svelte will ignore unused CSS in that component? Which I think opens up more possibilities for pitfalls, and an explicit opt in to keep styles would be a lot better here.

[tanhauhau]

Can I try?

@baseballyama yup go for it 🚀

[baseballyama]

There is actual problem here regarding CSS purging, so I think we need to discuss about it.
And I think I should wait to handle this until then.

#5804 (comment)

[sherifsalah]

@tanhauhau what about the suggestion of making something like :global keyword to keep classes that we don't wanna purge, this will solve another issue of keeping conditional classes as well as example:
repl
condtional class red will be purged so when the condition changes class red won't be found, should we create a new issue?

[tanhauhau]

the repl didnt use <svelte:element> at all, is this a similar issue or a different issue?

[sherifsalah]

the repl didnt use <svelte:element> at all, is this a similar issue or a different issue?

Different issue i guess, but it just popped up with this discussion, the idea of preventing svelte from purging certian classes (conditional classes), same as using :global but keeping it scoped as example: :keep(.class) {color: red}

[Conduitry]

This is supported now in 3.51.0 - https://svelte.dev/repl/23d982fc6f4f4f06a6aa227860fa2d84?version=3.51.0