What about CSS?

[pygy]

Some librairies (I'm thinking of CodeMirror here, but others apply too, I'm sure) come with large style sheets that are better loaded asynchronously too, and it is always nice to wait for the CSS to load as well as the lib itself.

I'm ignorant about the topic, but something tells me that there must be various pitfalls in that regard too...

Is it beyond the scope of little_loader?

This may end up being a slippery slope though (why not handle images, etc...), and I'd understand if you wanted to keep your lib lean and focused.

[ryan-roemer]

@pygy -- Offhand, JS with the tightest library is the main goal.

Curious -- what would be the likely percentage increase in size for CSS loading supporting the same browser matrix if you had to guess?

[pygy]

No idea off the bat, as I said, I'm ignorant about the topic. I've don it the naive way, using onload and ignoring errors, but that's precisely what you're avoiding here :-)...

Thinking aloud:

A naive approach (which may be sufficient) would be to dispatch on the extension and create a link tag rather than a script tag. Maybe ensure that the elements are appended in order rather than backwards[0]... I don't know how the cascade works when rules are inserted dynamically. Is it the document order or the time order that prevails on rule conflict?

There may be loaded vs applied distinctions, I'm not aware of it, and I wouldn't know how to write test to look for callbacks fired too early... I guess that checking, on load, the computed style of an element modified by the sheet could do it.

---

[0] More generally you may want to append scripts at the end of head. Imagine a wicked script that removes all script tags... Are there issues with head.appendChild?

[ryan-roemer]

@alexlande @exogen -- Interested in your thoughts on this in terms of (1) size of a css implementation, (2) consistency with the "super small" aims of little-loader, (3) should it be a separate project, etc.???

[alexlande]

I can't speak to how well CSS loading would fit into little-loader specifically. My gut instinct would be that there isn't enough commonality to make little-loader support CSS vs a separate CSS loading module.

I wouldn't expect the size of a CSS implementation to be very large, but am unaware of what potential pitfalls there are. I typically use https://github.com/filamentgroup/loadCSS for this, which is quite small. I have no idea how correct the behavior is cross-browser though. (Could be that working around edge cases as little-loader does would make the implementation much larger, although I would be sort of surprised.)

[exogen]

I've done a CSS loader implementation before and my impression was that getting reliable onload and onerror handling across browsers is even more difficult than with scripts. I'm not against looking into it at all though.

If we do add CSS loading, I'd prefer it to be a separate function entirely, no checking for .css at the end or css! at the beginning like many other solutions do.

[ryan-roemer]

@pygy -- Based on the feedback of @exogen and @alexlande who are pretty familiar with this, I'm going to close this as wontfix as it sounds like the right thing to do would be to open a new little-loader-css project or something if needed since we wouldn't share code in the core library.

Thanks for the submission!

[pygy]

You're welcome. Let's keep it simple!