docs: add FAQ about why you can't keep unused styles #9193
Conversation
|
documentation/docs/05-misc/01-faq.md
Outdated
| No. | ||
|
|
||
| Svelte's component style scoping works by generating a class unique to the given component, and then adding it to the relevant elements in the component that are under Svelte's control, and then also adding it to each of the selectors in that component's styles. If the compiler can't see which elements a given selector applies to, it has two options if it were to keep it, both of them bad. | ||
|
|
||
| If it still adds the scoping class to the selector, there is no guarantee that it will match the expected elements in the component, especially if they were created by a child component or something like `{@html}`. If it keeps the selector without adding the scoping class to it, it will become a global style, affecting your entire page. The third option, which is what Svelte takes, is to remove the styles from the component and warn you about them. | ||
|
|
||
| If you need to style something that Svelte can't identify at compile time, you will need to explicitly opt in to global styles by using `:global(...)`. But also keep in mind that you can wrap `:global(...)` around only part of a selector. `.foo :global(.bar) { ... }` will style any `.bar` elements that appear within the component's `.foo` elements. As long as there's some parent element in the current component to start from, partially global selectors like this will almost always be able to get you what you want. |
There was a problem hiding this comment.
thanks for writing this up! what do you think about this minor re-arrangement
| No. | |
| Svelte's component style scoping works by generating a class unique to the given component, and then adding it to the relevant elements in the component that are under Svelte's control, and then also adding it to each of the selectors in that component's styles. If the compiler can't see which elements a given selector applies to, it has two options if it were to keep it, both of them bad. | |
| If it still adds the scoping class to the selector, there is no guarantee that it will match the expected elements in the component, especially if they were created by a child component or something like `{@html}`. If it keeps the selector without adding the scoping class to it, it will become a global style, affecting your entire page. The third option, which is what Svelte takes, is to remove the styles from the component and warn you about them. | |
| If you need to style something that Svelte can't identify at compile time, you will need to explicitly opt in to global styles by using `:global(...)`. But also keep in mind that you can wrap `:global(...)` around only part of a selector. `.foo :global(.bar) { ... }` will style any `.bar` elements that appear within the component's `.foo` elements. As long as there's some parent element in the current component to start from, partially global selectors like this will almost always be able to get you what you want. | |
| No. Svelte removes the styles from the component and warns you about them in order to prevent issues that would otherwise arise. | |
| Svelte's component style scoping works by generating a class unique to the given component, adding it to the relevant elements in the component that are under Svelte's control, and then adding it to each of the selectors in that component's styles. There would be two bad options for keeping a style selector in a case where the compiler can't see which elements it applies to: | |
| - If it still adds the scoping class to the selector, there is no guarantee that the given style will match the expected elements in the component, especially if they were created by a child component or something like `{@html}`. | |
| - If it keeps the selector without adding the scoping class to it, the given style will become a global style, affecting your entire page. | |
| If you need to style something that Svelte can't identify at compile time, you will need to explicitly opt into global styles by using `:global(...)`. But also keep in mind that you can wrap `:global(...)` around only part of a selector. `.foo :global(.bar) { ... }` will style any `.bar` elements that appear within the component's `.foo` elements. As long as there's some parent element in the current component to start from, partially global selectors like this will almost always be able to get you what you want. |
There was a problem hiding this comment.
Thanks! I've tweaked your suggestions a bit and have pushed e16e0a3.
There was a problem hiding this comment.
documentation/docs/05-misc/01-faq.md
Outdated
|
|
||
| Svelte's component style scoping works by generating a class unique to the given component, adding it to the relevant elements in the component that are under Svelte's control, and then adding it to each of the selectors in that component's styles. When the compiler can't see what elements a style selector applies to, there would be two bad options for keeping it: | ||
|
|
||
| - If it keeps the selector and adds the scoping scoping class to it, there is no guarantee that the selector will match the expected elements in the component, and they definitely won't if they were created by a child component or `{@html ...}`. |
There was a problem hiding this comment.
For some reason github won't let me make a suggestion here, but: 'there is no guarantee that the selector will match the expected elements' is incorrect, I think? it's guaranteed not to match anything;
If it keeps the selector and adds the scoping class to it, it won't match any elements inside the component
Also, I'm not sure if 'scoping scoping' was a reference to the fact that we sometimes add the scoping class twice
There was a problem hiding this comment.
It could theoretically match, I think, if the user programmatically added a matching class to an element that was already getting the scoping class applied for another reason. (This is also adjacent to what Dominik and I were discussing in Discord about vite-plugin-svelte's behavior.) Since this is the FAQ entry we'll point people to when they request this feature which seems quite reasonable on the surface, I wanted to be very careful about what I say is impossible versus just unlikely. I'm happy to change this to something else if you think that would be a good idea.
lol, 'scoping scoping' is in fact a copyediting failure. Will fix.
There was a problem hiding this comment.
I tweaked "no guarantee" to "likely not". Will go ahead and merge now. Feel free to tweak or revert if you disagree with my change
4 participants
I finally sat down and wrote this. It may not stem the tide of feature requests, but it would be helpful to have a single thing to point at. I'd love some feedback on the wording here.
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint