Support global styles - Allow multiple top-level style tag declarations with different attributes

[btakita]

There are a couple of plugins that support globally scoped style tags.

https://www.npmjs.com/package/svelte-preprocess-css-global

https://www.npmjs.com/package/@ctx-core/sass

This naturally leads to the pattern to have both a global & a non-global style block for a component.

<style type=text/scss global>
</style>
<style type=text/scss>
</style>
<style type=text/css>
</style>

Unfortunately, Svelte gives an error You can only have one top-level <style> tag per component. Since there is some usage of global style tags, along with a rfc, it's time to modify this requirement if there are <style> tags with different attributes.

[Conduitry]

What do you think Svelte should do in this case? Just treat all of the style rules in all of the style tags equally?

Adding this in a naive way would be a breaking change for tooling that relies on the current AST structure, because that currently only provides a way for there to be one style tag. I don't know whether this is enough of a reason to not do it.

[btakita]

It seems like this would entail supporting an array of style blocks, instead of single block. The style blocks can then be processed with their respective processors (via the type attribute) & then combined into a single stylesheet for the component, which would each be combined during the build process.

Most components would only have a single <style> element.

In the AST, is the <style>element processed to CSS or is it unprocessed? If the <style> is processed, then combining the processed source <style> elements into a single <style> would result in the same AST structure. This would also involve a source map linking the processed <style>to the source <style>.

In the case of unprocessed <style> elements in the AST (source maps?), I suspect the failure mode of tools expecting one <style> is to only process the first <style>.

Is there a formal grammar of a svelte component somewhere?

[o-t-w]

I think it absolutely is worth potentially breaking things to make this change. Personally, in general, I don't use scoped styles, but like to keep open the option of using them as they are sometimes useful.

[marlonmleite]

@Conduitry supporting free styles is very important, for example how to use bootstrap with customElement? Currently not possible.

[antony]

It has been determined that there is a fundamental need for the functionality this provides, but this isn't the right approach. This approach is however currently available with preprocessors. Moving discussion to sveltejs/rfcs#13