Single-brace tags make inline non-root styles impractical

[Conduitry]

The v2 change of {{expression}} to {expression} wreaks havoc with inline non-root style tags, which are getting parsed for them so we can interpolate the styles at runtime. This is quite inconvenient, as things that are enclosed in braces happen (surprise!) all the time in CSS. I don't know what's a good way to reconcile this.

[Rich-Harris]

I would argue that non-top-level <script> and <style> tags are something of an anti-pattern. It's a bit weird to potentially have multiple identical <style> tags, and weirder still if they're not identical because they contain {tags} (since they'd all conflict, resulting in broken behaviour).

What are the uses for them? Maybe those uses can be met some other way.

[Conduitry]

I'm using them not infrequently on pages where I'm using Svelte SSR as a static site generation tool. I could use external css/js files for all of those but that doesn't always make the most sense.

[Rich-Harris]

Are you using interpolation? What if the contents of <script> and <style> went through as-is? Or are there valid uses of {tags}?

[Conduitry]

I'm not personally using interpolation, but it has its proponent(s). This is something that used to work, then was unknowingly broken (because it was never actually an intended feature), and then re-added when it was requested. I'd be fine with passing through the style tags as-is, but I don't think everyone would be.

[Rich-Harris]

Oops, I wasn't really paying attention to that issue. I would argue that there are much better ways to solve that problem than placing tags inside a nested <style> element — ways that don't break scoping, don't result in waste and/or broken styles if you have multiple components, and have much better performance characteristics.

If the styles are known at build time it could be done with preprocess; if not, with CSS variables. If you need IE11 support then it gets slightly trickier (no variables), but I don't think that's a good enough reason to interpolate given the many problems it raises. I'd be in favour of removing that ability for v2.

[Conduitry]

Well I'll defer to you on the User Alienation Decisions, but removing interpolation does indeed to seem the most straightforward path. I'll work on a PR, it should be a pretty simple change.

[Rich-Harris]

I think a good framework should protect you from footguns, even the really tempting ones.

@cristinecula since you opened #1147, a heads-up: we're planning to remove interpolation inside <script> and <style> elements for version 2, for the reasons outlined in this issue. Hope that doesn't cause you too much pain!

[cristinecula]

@Rich-Harris thanks for the heads up!