CSS preprocessors?

[punmechanic]

Just wondering how Svelte ties in to existing CSS preprocessors? I'm not seeing any documentation around this, and I'm not expecting it to just magically work if I add less or scss content to my style tags.

This would mainly be useful when using existing frameworks like Bootstrap.

[Rich-Harris]

Right now, this isn't supported. It's come up previously in the context of compile-to-JS languages (https://github.com/sveltejs/svelte/issues/98), and tangentially in the context of creating components from multiple files (i.e. a linked stylesheet/script) in https://github.com/sveltejs/svelte/issues/65. But until then, it would be a case of preprocessing the CSS and creating a single-file component to hand off to Svelte.

[nsaunders]

FWIW, we made our own svelte-cli analog that runs the stylesheet through the less compiler and then hands the result off to the svelte compiler. I can't open-source it because my employer doesn't understand the benefits, but it wasn't hard. Currently I am trying to modify a fork of the svelte-loader to use our compiler that wraps less and svelte.

[dschulten]

@therealnicksaunders What did you use as extension point in svelte-cli? It would make sense to introduce an official compiler-plugin api to svelte-cli which allows to process compilation steps. See also #194

[nsaunders]

@dschulten we didn't need most of the options in svelte-cli so I wrote our version from scratch. It consumes our xxxxx-svelte library that has a compile method that takes care of less precompilation and then passes the result to svelte's compile method. The API pretty much matches svelte, with the main difference being that it is asynchronous due to the less API being asynchronous.

I guess my point was that it was not terribly difficult as an interim solution, but I agree that this is going to be something a lot of people want out-of-the-box.

Maybe a good first step would be to make svelte's compile method asynchronous. That would have allowed me to fork svelte-cli, svelte-loader, et cetera, and leave them mostly unmodified (just swapping out the svelte dependency in favor of our own version).

[colshacol]

I don't think it would take more than an hour or two to create a simple npm package that would pre-parse the Svelte HTML files for <style> enclosures, pass that through the compiler of your choice, then pass the entire file on to Svelte. It would be hacky, but it'd work for now.

I may work on this this evening.

[praneybehl]

Has this been implemented yet?

[Rich-Harris]

Not yet, no

[kazzkiq]

The only thing keeping Svelte from being approved for a big project right now is the lack of official support for SASS/SCSS by the framework (which is a must for all company projects where I work).

Has anyone managed to "hack" SASS support into Svelte? If yes, do you guys have any tips or perhaps a code sample to share?

[PaulBGD]

The main issue is that Svelte can't just add support for SASS, it has to add full support for any CSS preprocessors. Svelte also modifies the generated CSS, so the build process has to actually be handled by Svelte as well.

[piyushchauhan2011]

I'm currently just using the scss through webpack build process. Having to use the hash based css names through sass, ahh - someone might need to have a go at that or CSS modules thing. I think, due to compilation everything is very limited to change, like supporting Sass and TypeScript. I would love to learn more about the patterns that could be invented for it to become approved for bigger projects.

[marianoviola]

My current CSS build process consists in creating a single-file component as suggested by @Rich-Harris, importing it in my global style file which is then processed by postcss-nextcss.

However, I'm experiencing the following issues:

• Svelte doesn't support some postcss-nextcss features which I regularly use in my projects such as custom properties sets, custom media queries/ranges and nested selectors (raising an error during compilation)
• Every time the components.css file is updated (in my case by Rollup), I need to rerun the global style build script in order to include the updated components. In this way I'm able to reuse global custom properties

At the end the build process works but I can't use many useful nextcss features in scoped style, and the overall build process is quite slow causing unwanted Browsersync reloads.

Do you have any suggestion to improve it?

[jslegers]

@Rich-Harris

Instead of implementing features like transitions (https://github.com/sveltejs/svelte/issues/525) & easing functions (https://github.com/sveltejs/svelte/issues/549) in Svelte, doesn't it make more sense to add support for CSS preprocessors like Less & Sass and use preprocessors to add custom transition behavior to components?

It seems to me that high level features like transitions & easing don't really belong in a framework like Svelte, whereas preprocessor support is pretty much essential for many companies to even consider using a framework like Svelte.

[Rich-Harris]

Preprocessors can't help you with transitions (which are already implemented, but need a section in the docs) — that needs to be a framework-level feature. No amount of CSS could do this, for example:

https://svelte.technology/repl?version=1.29.0&gist=f94338ee682bddccb8596874cad5b68d

For one thing, you can't use an easing function like that in a CSS animation. For another, if Svelte were to remove the <span> from the DOM immediately (because it didn't know about the out transition), it would be impossible to smoothly fade it out. Svelte transitions let you build fairly complex (and data-driven, via parameters) intro/outro effects that would be impossible with CSS itself, but that use CSS animations under the hood (i.e. off the main thread).

Realistically, we have two choices:

1. Wait until v2, so we can make svelte.compile async — without that, it's impossible to plug in support for some preprocessors
2. Let build tool plugins like rollup-plugin-svelte do the preprocessing. That's not ideal, because it needs to be implemented by every build tool plugin separately

In the meantime, it's totally possible to use preprocessors with something like this pseudo-code:

code = code
  .replace(/<style>(.+)<\/style>/, (m, styles) => `<style>${preprocess(styles)}</style>`)

[jslegers]

No amount of CSS could do this. For one thing, you can't use an easing function like that in a CSS animation.

Really? Doesn't the transition-timing-function property in combination with the cubic-bezier keyword allow you do achieve pretty much the same result, but with better performance?

Pretty much every modern browser supports this, including IE > 9.

Or is there something I'm missing here?

if Svelte were to remove the <span> from the DOM immediately (because it didn't know about the out transition), it would be impossible to smoothly fade it out.

Sure, it does require some trickery to do transitions in CSS right, especially if you're hiding & showing things. But again, this is nothing that can't be done with just SCSS.

Svelte transitions let you build fairly complex (and data-driven, via parameters) intro/outro effects that would be impossible with CSS itself, but that use CSS animations under the hood (i.e. off the main thread).

Again, that's precisely what languages like SCSS are for. Sure, many people use them only for parameterization, but the language is far more powerful than that.

Wait until v2, so we can make svelte.compile async — without that, it's impossible to plug in support for some preprocessors

Works for me, I guess. When is v2 expected to be released?

In the meantime, it's totally possible to use preprocessors with something like this pseudo-code:

code = code
  .replace(/<style>(.+)<\/style>/, (m, styles) => `<style>${preprocess(styles)}</style>`)

No thanks!

Having to use dirty hacks like this as workarounds to implement a missing feature as essential as SCSS support is a good reason not to use this framework for the time being. I think I'll just wait ;-)

[nsaunders]

@jslegers Pretty much what @Rich-Harris said. On our project, we built a tiny CSS preprocessing Webpack loader that is applied to *.html files before they are handed off to the svelte-loader. The loader looks for inline LESS stylesheets via a regex similar to Rich's, runs their contents through the LESS compiler, and then replaces the original stylesheet with the processed stylesheet. We used the less-loader's getOptions service which even made it easy to tie into Webpack's module loading system for LESS imports and such.

This has worked flawlessly for us, so maybe your team can do something similar?

[jslegers]

This has worked flawlessly for us, so maybe your team can do something similar?

I'm looking at Svelte first and foremost as a foundation upon which to build version 2 of Cascade Framework, which is a one-man project I do in my spare time. The project being first and foremost a CSS framework makes native SCSS support pretty essential.

At my employer's, the current approach for the frontend of our products is to use TypeScript + React + Webpack. I'd really love to recommend Svelte + Rollup or Svelte + Webpack as an alternative for React + Webpack, but here as well I consider native SCSS support a rather essential feature. TypeScript support (https://github.com/sveltejs/svelte/issues/98) would also be pretty essential. And even that wouldn't be enough, I'm afraid, to convince my colleagues to make that kind of investment. I'll need a much stronger case to convince anyone to replace React + Webpack with an alternative that sure looks promising but doesn't seem mature enough just yet.

[rhengles]

There is already an issue for that - #65 - and it's on the roadmap (#622) under "Medium term".

[Rich-Harris]

Or is there something I'm missing here?

Yep. cubic-bezier is very limited. You can't do the elastic easing function I showed above, for example.

Sure, it does require some trickery to do transitions in CSS right, especially if you're hiding & showing things. But again, this is nothing that can't be done with just SCSS.

There's no way to style an element that's no longer in the DOM. You have to delay the removal of the node from the DOM. In other words, the framework needs to understand whether or not a given element has an outro transition — i.e., a framework-level feature.

Again, that's precisely what languages like SCSS are for.

SCSS can't do things like vary the duration of a transition based on some value that isn't known until runtime.

Works for me, I guess. When is v2 expected to be released?

When it's done 😉

Just as an aside, saying things like 'that wouldn't be enough, I'm afraid, to convince my colleagues to make that kind of investment' doesn't motivate the maintainers of OSS projects to drop everything to support your use case — it just creates antagonism. This is a project that the other maintainers and I work on in our spare time. If you want a particular feature to land sooner, here's the link you're looking for!

[jslegers]

Yep. cubic-bezier is very limited. You can't do the elastic easing function I showed above, for example.

* oops *

What about a sequence of key-frames?

There's no way to style an element that's no longer in the DOM. You have to delay the removal of the node from the DOM.

In such a case, can't you just add/remove a class with a CSS transition, timeout to allow the transition to render and then remove the element from the DOM?

SCSS can't do things like vary the duration of a transition based on some value that isn't known until runtime.

Fair enough. How often do you need that, though? The number of use cases that requires the duration of a transition to be determined at runtime seems pretty small to me.

Just as an aside, saying things like 'that wouldn't be enough, I'm afraid, to convince my colleagues to make that kind of investment' doesn't motivate the maintainers of OSS projects to drop everything to support your use case — it just creates antagonism.

I'm sorry if I sound antagonistic. That's 100% unintended. In fact, I haven't been as exited about any open source project as much I am about Svelte in years.

And Rollup looks just as promising by what I've seen so far, so kudos for that as well! 👍

Anyway, I absolutely love where you're going with Svelte & I'm seriously considering it as a foundation for my own open source projects once it has features like native SCSS support & named scoping (https://github.com/sveltejs/svelte/issues/570).

I guess I'll have to work some more on my social skills if I hadn't made that clear enough ;-)

[Rich-Harris]

Thanks — it's all cool, it's just very hard to balance all the competing feature requests while keeping the project focused and maintainable. Svelte will never 'natively' support SCSS, insofar as that means including node-sass and using it without some form of configuration, because that kind of coupling is dangerous. It's more likely to look something like this:

import svelte from 'svelte';
import scss from 'svelte-scss';

const code = `
<div><p>styled with SCSS</p></div>

<style type='scss'>
  div {
    p {
      color: red;
    }
  }
</style>
`;

svelte.compile(code, { preprocess: { scss } })
  .then(result => ...);

That way, we just need to define a preprocessor interface and it can be reused with LESS, postcss, etc.

[jslegers]

it's just very hard to balance all the competing feature requests while keeping the project focused and maintainable.

I know. I work in R&D professionally & have my own open source projects on the side. I know where you're coming from. I feel your pain ;-)

I guess I'm just trying to throw in my 5 cents as I really really love where the Svelte core framework is heading in general. It's just missing a few features that are pretty essential to me, and I guess I'm just frustrated that features like transitions are getting so much attention that could have been used on improving the core, the build process or the docs...

But hey... it's not my project and I don't even have enough time for my own projects at the moment, so sorry again if I come off as ungrateful or greedy :-)

It's more likely to look something like this

What would work for me, I guess, would be an officially supported way to plug node-sass into the standard build process.

As an "end user", I expect to be able to write my components like this...

<div><p>styled with SCSS</p></div>
<style>
  div {
    p {
      color: red;
    }
  }
</style>

... and just run npm run build, the exact same way I'd do it if it my styles were CSS instead of SCSS.

Am I OK with having an extra build step in the build process? Sure! Am I OK with having to install a separate plugin to add this feature? Sure!

I see why you'd want to separate preprocessor support from the core library, but adding SCSS or Less support shouldn't be any more complicated than adding a plugin... and I don't want to have to write my own plugins or look for third party plugins for something as elementary as SCSS support!

"End users" shouldn't have to know anything about the build process other than how to run it. They should be able to treat it like a black box. It shouldn't matter to an "end user" of Svelte whether it's Rollup or Webpack that's under the hood and how many build steps are used to get from src to dist. And they shouldn't have to write their own build processes for adding preprocessor support.

Also, I don't want to risk losing my preprocessor support every time I upgrade the Svelte build process. Without at least an officially supported plugin for preprocessor support, the chances of that occuring are pretty high.

[PaulBGD]

What would work for me, I guess, would be an officially supported way to plug node-sass into the standard build process.

That would be the point of this issue then!

[nsaunders]

I'm going to add some fuel to the fire here and state my current position that CSS preprocessing is a separate concern and should not be handled by Svelte at all. svelte-cli might give the impression that Svelte is the build process, but, frankly, for any non-trivial project (like the kind that would require CSS preprocessing), Svelte should be merely one step in the build process. Let the Svelte compiler itself focus on the native languages of the Web (CSS, HTML, JavaScript) and keep unnecessary complexity out!

Instead of lobbying for plugins or CSS preprocessing in the Svelte core, perhaps our little Svelte community should tackle the problem of real build tools like Webpack, Browserify, Rollup, et cetra, lacking the necessary plugins/loaders to process HTML modules. (For example, as I previously explained, Webpack has less-loader, but I couldn't find a loader that could be applied to an HTML file with inlined LESS). This is a relatively easy problem for just about anybody to solve, as it only requires knowledge of the build tool and some string manipulation. It is way easier than working on the source of the Svelte compiler.

I think it's up to @Rich-Harris to guide the direction of this "anti-framework". But if I were him, I would strongly prefer to outsource the CSS preprocessing problem instead of wasting my time trying to build and maintain a plugin API that is perhaps unnecessary.

[Conduitry]

Yeah I think I largely agree with @therealnicksaunders . Perhaps the only "plugin API" that Svelte needs to support here is that it can generate sourcemaps leading back to the original sources if its input included sourcemaps.

[Rich-Harris]

Yep, the sourcemap stuff is crucial, and also incredibly finicky to try and stitch back together later unless it's part of the compiler. The other place where Svelte might need to have some awareness of its surroundings is in dealing with @import — if two of my components have SCSS in <style> tags that both @import the same file, then the only way we can avoid duplicating that code is if Svelte understands that concept.

But I want to keep that stuff out of the core to the greatest degree possible while still supporting these use cases. For one thing, supporting compile-to-X languages is a source of fragmentation — if your component uses SCSS, then my app can't import it unless I configure my compiler instance to deal with your authoring decisions.

Ultimately, I want preprocessors to die. I used to use them all the time, but eventually I came to the realisation that 90% of what I was using them for was nesting, which is kind of unnecessary when you have styles that are scoped to the current component. 9% was variables, which is a problem that can be solved in other ways, I think. The last 1% was stuff like mixins, which are theoretically useful but which I found myself having to consult documentation for every single time. The thing that finally convinced me to stop using preprocessors was the realisation that I was wasting so much time tweaking styles in devtools then manually converting the resulting styles back into SCSS (replacing colours with variables, etc etc) in order to paste them back into my source code. When you just use CSS, there's so much less friction.

But there are lots of people for whom preprocessors clearly are useful, and I think Svelte should make it possible to support those workflows, while not explicitly encouraging them.

[jslegers]

Ultimately, I want preprocessors to die. I used to use them all the time, but eventually I came to the realisation that 90% of what I was using them for was nesting, which is kind of unnecessary when you have styles that are scoped to the current component. 9% was variables, which is a problem that can be solved in other ways, I think. The last 1% was stuff like mixins, which are theoretically useful but which I found myself having to consult documentation for every single time.

That's like arguing that JavaScript sucks, basing it only on your experiences with jQuery.

When you just use CSS, there's so much less friction.

That's like arguing vanilla JS is so much easier than React or Svelte because all you ever use JavaScript for is a bunch of Ajax calls and click events.

[Rich-Harris]

That's like arguing that JavaScript sucks, basing it only on your experiences with jQuery.

I've used SCSS, LESS and postcss extensively.

[jslegers]

I've used SCSS, LESS and postcss extensively.

You said yourself that 90% of what you used it for was nesting and 9% was variables.

That's the CSS preprocessor equivalent of only writing basic Ajax calls & click handlers with jQuery.

[Rich-Harris]

a) I mean that's what they turned out to be good for, when I reviewed my usage of them, and b) don't take the numbers super literally. I was just making a point. The upshot here is that having used preprocessors a lot over the years, I'm much happier writing plain CSS.

I'd implore you to think a little bit before making some of these comments, they're coming off as very patronising.

[jslegers]

I'm just saying you can't judge a language or framework if you've been using <5% of its functionality >95% of the time.

SCSS is a pretty powerful language that's unfortunately totally underused beyond the most basic features because most people using it are designers who barely know how to program and most JavaScript programmers don't bother to learn most of the language's features because they're too busy writing JavaScript code.

Now, if you were talking about JS preprocessors, I'd agree. I never quite understood the popularity of TypeScript or Babel, really. ES5 + a few polyfilled ES6 features here and there can do the job quite fine, and all TypeScript and Babel do, IMO, is add a bunch of unnecessary abstractions between the code you write and the code that's run in the browser that does more to cause headaches than to prevent them.

I guess it all depends on your very personal experience and taste. And again, sorry if my comments come off more antagonizing than intended. Having discussions without getting under people's skin isn't one on my talents... especially online.

[bigopon]

@jslegers mind sharing some of the usage that can demonstrate that it is powerful, but underused or gets too little attention?

[jslegers]

For example, I'm thinking about writing stuff like this...

.s1 {
  @include rules((
    float : right,
    width : 30%,
    background : #fff,
  ));
}

.s2 {
  @include rules((
    float : right,
    width : 100%,
    background : #000,
  ));
}

.s3 {
  @include rules((
    float : left,
    width : 30%,
    background : #fff,
  ));
}

.s4 {
  @include rules((
    float : left,
    width : 40%,
    background : 'url(image/cool-background.jpg)',
  ));
}

... to produce output like this :

.s1, .s2 {
  float: right; }

.s1, .s3 {
  width: 30%; }

.s1, .s3 {
  background: #fff; }

.s2 {
  width: 100%; }

.s2 {
  background: #000; }

.s3, .s4 {
  float: left; }

.s4 {
  width: 40%; }

.s4 {
  background: "url(image/cool-background.jpg)"; }

See https://gist.github.com/jslegers/9805919 for the complete demo.

[morewry]

These are my reasons and preferences for use case and feedback purposes.

I actually agree that a great deal of what preprocessors were both useful for and perceived as useful for in the past is either no longer relevant, or in my opinion, turned out to be not quite worth the trouble.

• I only cared for nesting selectors like &:hover, because nesting crossed the line into bad for style architecture real quick in global CSS.
• "Native" CSS variables can be a feasible choice now.
• The perceived modularity of a Sass partial is more often than not an illusion (meh to "components"-via-information-architecture).

I find that after creating UI component systems that integrate and isolate the behavior and appearance of a GUI pattern that you have to approach things a bit differently than you did a CSS Framework. But the previous approach is of course the source of many preprocessor features.

Personally I still want to use a preprocessor along the lines of PostCSS and a plugin like postcss-cssnext. Svelte is already taking an analogous approach to that setup with the JavaScript in its modules by using import and export, features not natively supported by all browsers and which are being compiled. Granted, there are critical distinctions between transpiling "future CSS" and transpiling "future JS" due to differences in how the standards for each evolve as well as in CSS being a language whose future features are more often not unable to be reproduced using current CSS alone unless browsers have implemented with vendor prefixes.

There are few more reasons that matter to me:

• There's the transition from CSS frameworks to UI component libraries to consider. There's lots of code in preprocessor formats that developers want or need to continue using instead of having to rewrite another way.
• I've also found that I still want to share certain styles that aren't composable at the same abstraction level as an integrated UI component, but, instead, are best as pure styles I can grab (mixin-esque). For this purpose, Sass/LESS/Stylus/PostCSS or CSS Modules are pretty essential to have in our toolbox.

Initially I thought I could use the CLI options to output a stylesheet and run PostCSS on it, which I thought was good enough for now. But now I hear there will be errors and realize it will change the experience for component users, so maybe not.

Of the ideas proposed,

...perhaps our little Svelte community should tackle the problem of real build tools like Webpack, Browserify, Rollup, et cetra, lacking the necessary plugins/loaders to process HTML modules. (For example, as I previously explained, Webpack has less-loader, but I couldn't find a loader that could be applied to an HTML file with inlined LESS). This is a relatively easy problem for just about anybody to solve, as it only requires knowledge of the build tool and some string manipulation. It is way easier than working on the source of the Svelte compiler. - @therealnicksaunders

That makes sense. I've come across plugins that do similar things in the past. But it seems to me from the outside that the most appropriate time to preprocess the style is during the build runtime after Svelte has extracted the style from the input HTML source file, but before Svelte places the stringified style in the output JS distribution file. The other options of doing something either before or after Svelte's process looks less than ideal right now...

• It doesn't make sense to me to extract and process the stringified style in the output JS after Svelte is finished.
• But neither does it make sense to overwrite your source HTML file with a preprocessed one or to make a copy of the preprocessed HTML for Svelte to pick up as its input file.
• Nor for every user to have to write a custom script (or rely on their particular ecosystem having a plugin).

It would make sense to introduce an official compiler-plugin api to svelte-cli which allows to process compilation steps. - @dschulten

I like when tools are extensible and flexible, so I like this idea. But I also note that there sure is a proliferation of small build plugins that exist only to glue another tool into Gulp/Webpack/Rollup/etc. It'd sure be nice if it could re-use the plugins from one or more existing ecosystems rather than having a unique plugin API--or didn't necessarily need a plugin to use modules like node-sass or postcss.

While you're considering this type of thing in terms of CSS preprocessing and alternative JavaScript syntaxes, I'd like to mention PostHTML. Svelte templates have their own syntax and outside of templating purposes, processing HTML is not as popular, but I hope there could be symmetry that will enable HTML pre/post-processing in addition to CSS and JS. It could allow some potential feature requests (e.g. minification, global custom attributes) to be served by third parties rather than Svelte itself.

[jslegers]

• I only cared for nesting selectors like &:hover, because nesting crossed the line into bad for style architecture real quick in global CSS.

@at-root to the rescue!

If you prefer BEM-like syntax to nested classes, you could use the @at-root directive to nest your SCSS without nesting the CSS output it produces.

So, you could do shit like this :

$theme : (
  simple : simple,
  xmas : theme-xmas
);

.form {
  @at-root .form__input {
    border: black;
  }

  @at-root .form__submit {
    background: black;

    @at-root .form__submit--disabled {
      background: grey;
    }
  }

  $simple : map-get($theme, simple);
  @at-root .form--#{$simple} {
    color: black;
  }

  $xmas : map-get($theme, xmas);
  @at-root .form--#{$xmas} {
    color: red;

    @at-root .form__input--#{$xmas} {
      border: red;
    }

    @at-root .form__submit--#{$xmas} {
      background: green;

      @at-root .form__submit--disabled--#{$xmas} {
        background: lightgreen;
      }
    }
  }
}

That would produce this :

.form__input {
  border: black; }

.form__submit {
  background: black; }
  .form__submit--disabled {
    background: grey; }

.form--simple {
  color: black; }

.form--theme-xmas {
  color: red; }
  .form__input--theme-xmas {
    border: red; }
  .form__submit--theme-xmas {
    background: green; }
    .form__submit--disabled--theme-xmas {
      background: lightgreen; }

Personally, I prefer a maximum of 3 levels of nesting, using simple, semantically named class based selectors + a select few ID based selectors when I want to get really specific. BEM syntax is way too ugly & convoluted for my taste, but some big names in the CSS world seem to love it for some reason...

• "Native" CSS variables can be a feasible choice now.

Not in the real world, where having to support IE is still a real thing.

Also, variables in CSS behave very differently from variables in LESS or Sass and IMO pretty counter-intuitively. Personally, I'm not inclined to use them any time soon!

• The perceived modularity of a Sass partial is more often than not an illusion (meh to "components"-via-information-architecture).

I'd agree that SCSS is missing a few features to make it truly dynamic, like conditional @imports within control directives and/or mixins? I've been waiting for this feature to be implemented for 3 years now!

To make things worse, the core devs don't seem to care about making SCSS more dynamic in spite of many, many people requesting such features. I feel like they're holding their own language back...

While you're considering this type of thing in terms of CSS preprocessing and alternative JavaScript syntaxes, I'd like to mention PostHTML. Svelte templates have their own syntax and outside of templating purposes, processing HTML is not as popular, but I hope there could be symmetry that will enable HTML pre/post-processing in addition to CSS and JS. It could allow some potential feature requests (e.g. minification, global custom attributes) to be served by third parties rather than Svelte itself.

Being able to choose whether or how to pre-process JS, CSS & HTML by just dropping in your preferred plugins (with minimal configuration) sure does sound like a killer feature to me!

[sp00m]

What about playing with the type attribute of <style /> tag somehow? This can lead to an elegant API for developers IMHO. For example for SCSS:

<!-- defaulted to text/css -->
<style type="text/x-scss">
  header {
    h1 {
      color: #BADA55;
    }
  }
</style>

Then, either natively embedded preprocessors or a manually added ones via plugins could transpile it at compile time.

This could be also used for <script /> tags actually. For example for TypeScript:

<!-- defaulted to application/javascript -->
<script type="application/x-typescript">
  function greeter(person: string) {
    return "Hello, " + person;
  }
</script>

Basically, one media type for one preprocessor.

I haven't yet thought of all the technical involvements that would be needed (nor checked what's currently being done to handle these transpilers TBH), and I'm very new to Svelte, but I just wanted to share my thoughts ;)

[morewry]

What about playing with the type attribute of