tef
commented
9 years ago Why do we do it the complicated way?
- Browsers are terrible
- Javascript breaks across platforms and renders differently
- When you hit print, you have no idea if they will come out/render properly.
- Resing the window may change everything
We have a mechanism that produces images, such that we don't rely on browsers working, they always render properly when printed out, they're trivially inlineable, they can be copied and pasted, or even saved easily. We can also use the images within PDFS.
That latter reason was one of the major reasons we pre-render scratchblocks, rather than crossing our fingers and hoping the browser works. (Hint; IT NEVER DOES)
It may seem like the complex way, but really it's the easy way for the people who end up using the lessons.
But that’s not obviously A Bad Thing – to me, at least.
The whole point of doing it as a pre-processing step is to make it easier, simpler, and reliable for the people who are reading the tutorials. Not to make it easier for the person running a build script, that's the wrong sort of person to optimize for.
Are there potentially unforeseen issues with doing it the easy way?
If it ain't broke...
My question is: Why, given that we have a mechanism, relatively encapsulated in the process, that produces pretty good images for scratchblocks, why would you want to replace it with a mechanism that might not work across browsers in uncertain ways?
andylolz
Paging @tef: this question is specifically directed to you!
Background
lesson_format runs pandoc with the custom pandoc_scratchblocks filter, which in turn uses scratchblocks2.js + phantom.js to generate scratchblock images that are embedded into html.
Alternative
An alternative would be to use scratchblocks2.js client-side, to render scratchblocks on the fly. This does add a dependency on javascript… But that’s not obviously A Bad Thing – to me, at least.
Question
Why do we do it the complicated way? Are there potentially unforeseen issues with doing it the easy way?
Thanks!