Transform for async loading css

[Munter]

There is a lot of talk about getting CSS, and especially CSS loaded fonts off the critical rendering path.
This script does this well: https://github.com/filamentgroup/loadCSS

We might want to provide a transform behind an option to do this

[silvenon]

That's a great idea. They recently released criticalCSS, which you could use.

For this a config file discussed in #74 would be really useful, because I don't think automatically extracting critical CSS is ever precise enough, so passing options via a config file could be much more readable.

[Munter]

But what would those options do?

I am more inclined to just say that people must curate their own manifest if a full automation is not acheiveable. Something like this could be an option:

<link rel="stylesheet" href="header.css" ag-critical>
<link rel="stylesheet" href="menu.css" ag-critical>
<link rel="stylesheet" href="content.css">
<link rel="stylesheet" href="footer.css">

[Munter]

It would probably be nicer to make this a general thing though. Like adding ?inline to the url of any asset inlines it in the appropriate representation

[silvenon]

These options, for example. ag-critical thing wouldn't work with Sass, where everything is concatenated all the time, right?

[Munter]

If people would stop using sass in the wrong way where they @import everything into a single file, then no, that won't work.

If they properly split up their stylesheets, like they should, it will work

[silvenon]

Yeah, I've written a post about that, but I changed my mind since then. I'd rather not import globals in each new stylesheet. But I never considered it a bad practice, interesting.

[Munter]

It's bad practice because when you start thinking about componentized UI you suddenly add a second reference to a file in the component fro your Sass main. That means you are adding two separate references to files in the component and messing up your dependency graph with it. Like so:

What you want is a single point of entry into your component. This will clear up the dependency graph, since it's the responsibility of the component itself to include its own styling. This makes components more self encapsulating and clears up the dependency graph so when you remove your single dependency on the component, all traces of it will be gone.

With Web components it will look like this:

With JS-based components it will look like this:

[silvenon]

You're right, with Web Components the issue is immediately obvious. I guess it's alright to enforce it, since people should be using Web Components anyways.