Scratch-blocks: CSS should not be inlined in JS

[tmickel]

We should separate out css.js into a separate file (or maybe even SASS).

Having every CSS line be a quoted JavaScript line is very difficult ergonomically.

Neil's justification for doing this was so that the CSS is loaded synchronously. But, we could load CSS "synchronously" by doing an XMLHttpRequest during Blockly.inject. Don't proceed to the actual body of inject until the request comes back, and then synchronously inject the CSS into the page after having done any kind of necessary transforms (e.g., $colour properties).

The other justification given is "It speeds up loading by not blocking on a separate HTTP transfer." I suspect this is significant enough to justify the bad ergonomics, but it's worth looking at. Maybe we should be using a build system that can inline CSS, like Webpack.

[NeilFraser]

Using XMLHttpRequest means CSS cannot be loaded in Chrome without a server. Local file:// urls would fail due to security restrictions. I believe I considered all available options before inlining the CSS.

Chrome has labeled this as "won't fix": https://bugs.chromium.org/p/chromium/issues/detail?id=37586

[nanaian]

@NeilFraser Use an HTTP server? Or if you somehow can't there's a --disable-web-security Chrome flag...

[carlosperate]

@NeilFraser Use an HTTP server? Or if you somehow can't there's a --disable-web-security Chrome flag...

Those feel like workarounds rather than solutions. The only alternative I can think of would be to update the build script to parse a css file into the javascript string to be inlined, but that wouldn't really work for the uncompressed version of blockly.

[nanaian]

Those feel like workarounds rather than solutions.

HTTP servers are not workarounds.

Scratch Blocks is likely going to be run on a server, no? Therefore semi-cloning a production workspace (i.e. using a simple server) isn't much of a workaround.

The only alternative I can think of would be to update the build script to parse a css file into the javascript string to be inlined

If you're going that route, you may as well use gulp & a css preprocessor, like Sass, when building.

[carlosperate]

Don't know if scratch blocks will be run on a server or not, but blockly has been designed with the advantage to be able to work in a static page just opened locally, I'm sure there are a blockly applications depending on that, and I could see the same extending to scatch-blocks derivatives. Adding a whole HTTP server just to be able to load a single css file seems a bit overkill.

If you're going that route, you may as well use gulp & a css preprocessor, like Sass, when building.

I guess that is always an option if you'd like to go that route, I don't quite see the need to add all those dependencies for such a small css project, but that is really up to the project to decide if it adds some value. However I just wanted to emphasise that this would be an additional layer on top of what I was describing, not an alternative way to achieve the same.

[matthewr6]

I'm sure there are a blockly applications depending on that

What can opening locally do for a web application that running on a server (even, say, Apache) can't?

@carlosperate You're describing things such as SimpleHTTPServer, gulp, and Sass as dependencies, most likely on the grounds that they will overcomplicate things.

The thing is, they're supposed to be used like that. JS files aren't supposed to be used as CSS.

[carlosperate]

What can opening locally do for a web application that running on a server (even, say, Apache) can't?

I don't think I'm explaining my point of view well enough. Obviously running a file locally does not offer any "additional functionality", but being able to run the application as a simple static page does have it's advantages. Sometimes you need to run these visual programming apps in computers with a lot of restrictions, from network restrictions (no network, or passing through a proxy, so no pip or npm), to the available software installed (not having Python or node), or not having the ability to run any executable (so even if you package the application you cannot run it). So giving up this great advantage of blockly just to load a single css file seems like a bit of shame. As developers we generally don't give too much thought to these things, but you'd be surprised the amount of great educational software schools are completely unable to use because of these reasons.

About using gulp, Sass, etc I've got nothing against it if it adds real value. I personally I don't really see it in this specific instance, but that's just my opinion. Of course you can feel differently, and everybody is free to use whatever tools they find useful.

[nanaian]

...being able to run the application as a simple static page does have it's advantages...

Completely agree with you there, :tada: but for the sheer amount of css that's going to be needed - especially for the vertical blocks - a JS string full of CSS is not going to be maintainable (especially because they've opted for the concatenation route).

@NeilFraser You should think about using webpack, sass, etc for this. Inlining CSS is, as I've said, a terrible idea.

[tmickel]

Hey all,

Thanks for the interesting and productive discussion. I agree all around.

For now it seems important to maintain the ease of development on a local (file://) basis, so I'm going to close this.

If/when we switch to using a build system that has the capability of inlining CSS automatically, we will fix this then.

You are right that we're going to be adding more and more CSS as we implement more of the vertical blocks. I hope it doesn't become unmanageable too fast :)

[mrjacobbloom]

If/when we switch to using a build system that has the capability of inlining CSS automatically, we will fix this then.

There were a bunch of changes to the build setup this morning (see LLK/scratch-gui#262 and related), now might be a convenient time to look back into this