The problem with dumping JS or CSS anywhere is the behavior becomes unpredictable.
One one hand it’s impossible to provide a WYSIWYG rendition of that code (for the reasons stated previously, an editor is either all visual or it exposes HTML concepts). We don’t want Sparkle to become a container for gray boxes. Also we don’t want sites built with a sprinkle of code to be a notch above sites built without, or there goes the visual nature of the tool.
On the other hand we want to guarantee that the page loads fast under all circumstances, but if you put a link to a CSS file, a script or other render-blocking code, the page won’t be as fast.
In a more under the hood way, we want to be free to significantly change the generated code in the future, say we switch to flexbox and the markup ends up being entirely different, any code that significantly interacts with the code that Sparkle generates today is going to break, and it’s going to be a nightmare to move forward. So we draw the line at “self contained piece of code”, like say a Google map or a Youtube embed (which we support directly, but they are good examples).
This means that some things today in Sparkle can’t be done. The good news is we release a bunch of updates throughout the year, and we’re happy to talk and integrate what makes sense to fit in. favicon is definitely ridiculous to have to set up manually, it’s in Sparkle since the original release.
Duncan
freewaytalk mailing list
email@hidden
Update your subscriptions at: