Blog-cells: Interactive code cells for static sites
rameshvarun.github.io
rameshvarun.github.io
But maybe using an <iframe> would make it a little more secure...
Example: what approach are you using in your hypothetical to actually get the cell contents into the iframe?
Most of the evolution of web dev can be described as people pushing the boundaries of what browsers were meant to do until standards caught up. I think iframes for running untrusted content is very standard now (https://caniuse.com/iframe-sandbox) with a lot of well supported safe guards built-in like treating the iframe as its own origin.
Obviously defense-in-depth is a good idea and you should be careful when setting up iframes, but if there's a good chance `iframe sandbox` is going to break in later browser releases, there's a lot of stuff you couldn't do anymore. Even with CSP, it would only reduce but not eliminate what an attacker could do.
That's not what I said.
Can you answer the question?: What approach are you using in your hypothetical to actually get the cell contents into the iframe?
No shared state between elements, but it’s an interesting idea.
Edit: It runs other languages as well, like Python, C, Ruby.
I've been looking for 'runnable C examples' on my blog.
Do you know if I can integrate this with Hugo easily?
If you’ve got a way to add node packages to your frontend then it is pretty straightforward. If not, using unpkg (https://unpkg.com/) in a script tag should work.
Happy to help you figure it out! Post in the discussion board on GitHub or email me (address on the website).
Two options: 1. Make every exported function a global, or just look like a global. 2. Force users to import and name the blocks
I think option 1 for this use case might actually be just fine.
I don't see anything special for that. No CORS proxy, no fetch monkey patching, nothing
E.g. you could use this in your GitHub Pages site, which is just served from a CDN without any real backend.
> Using pre tags instead of script tags
> Script tags are great for defining notebook cells since they can hold pretty much any code without escaping. However, they are invisible by default, meaning that readers won't see anything until blog-cells loads. You can get around this by using <pre class="notebook-cell"> tags instead, however reserved HTML characters should be escaped using HTML entities.
<pre class="notebook-cell">
console.log("<b>HELLO</b>");
</pre>
I was pleasantly surprised to see this. I know it's a bit less convenient to type because of the entities, but I believe this is the way to go and this should be the main, advertised, method. Progressive enhancement. Keep your content as accessible as possible :-)Now, I do think the result blocks would be better statically rendered if it's going to yield the same result each time they are run. The code runs once, at generation time, and the page is totally readable without JS. It indeed requires a generation step, but I think it's worth it, and blogs usually already have one.
I think Emacs has something like this with Org mode.
script[type="text/notebook-cell"] {
display: block;
}
Which stops you from having to type out all those entities.Once fully supported, you could even put this behind a media query (`@media (scripting: none)`) so you don't have to change the display with JavaScript after load.