Style/Script Defaults

[natemoo-re]

• Start Date: 2022-03-15
• Status: ✅ Accepted

Summary

Astro is inconsist between <style> and <script> default behavior. Currently, <style> has opt-out processing, but <script> does not. This RFC aims to settle on a good, consistent default for both <style> and <script>.

TLDR; <script hoist> becomes the default for <script>. is:inline introduced for <script> and <style>.

Links

• Full Rendered Proposal

[matthewp]

I have some clarifying questions posted above, but are not blocking in my mind. I agree with this RFC.

---

I'll add that I think <img> and <link rel="stylesheet"> should also be "automagic", but that is not blocking this RFC, happy to start a new one to discuss.

[bholmesdev]

RFC call notes: 03-15-2022

• Did not reach consensus
• Open questions:
  • Should lang:scss and is:inline work together? Currently not supported
  • Can is:raw be re-used instead of is:inline? - con: teaches user to use otherwise dangerous tag for HTML
  • We can use src= with <script hoist> currently. Should we still switch to is:inline as proposed? - current answer: no, we should probably ditch this from the RFC!

[sciencefidelity]

I found a use case for this. In the last few days I've been experimenting with creating html email templates that populate and compile from a CMS (Sanity). For this use case all styles need to be inlined, I'd prefer to use lang:scss.

I have some questions:

• Do is:inline styles get optimised?
• Where on the complied page do styles get inlined, (ie are they be moved to head)?
• What happens when multiple .astro components containing <style is:inline> compile to a single .html file?

[RafidMuhymin]

If there's no way to flag a <script> tag for hosting manually, and if adding any attributes or the define:vars directive will exclude the tag from hosting, then won't this approach break a few valid use cases? I think at least the define:vars directive should be supported for hoistin

[matthewp]

@RafidMuhymin define:vars already isn't supported for hoisting. We would like to support it but just haven't figured out how to do so. We need to build the JavaScript before rendering, but then some how feed the rendered variables back into it. It's a hard problem.

[tony-sull]

Added one comment related to potentially removing is:scoped, but not a blocker for me

Very happy to see how all this came together! It makes much more sense having styles and scripts handled in the same way, and defaulting to compiler/bundler magic makes sense since that seems to be the lion's share of real world use cases

[gloopsies]

@RafidMuhymin define:vars already isn't supported for hoisting. We would like to support it but just haven't figured out how to do so. We need to build the JavaScript before rendering, but then some how feed the rendered variables back into it. It's a hard problem.

I know that currently define:vars works by adding let variable = value, but that sounds wrong to me. Could Astro move to more of like a preprocessor way of replacing every occurrence of variable with it's value? or at least using const insted of let?

[FredKSchott]

Accepted during todays RFC call