http://idpf.org/epub/30/spec/epub30-changes.html#sec-new-cha...
First, there's opportunity for that web endpoint to stop functioning. Second, there's opportunity for that web endpoint to become taken over by malice. And third, there's opportunity to turn that caption space into an advertisement.
So, to put it succinctly: fuck no.
> This would allow you to display an "obsolete sample code" warning below the examples.
So now the book isn't timeless. It changes. It's no longer a book.
A better idea: include the "obsolete sample code" warning in the book and ask the user check for the latest practices at a URL also included in the book.
> When the user is not connected to the internet, you could display "Get online to know code snippet status". And so on.
When the user is not connected to the internet should be the only case ever considered for a book. Otherwise you're not writing a book. You're writing an app.
Cheers.
Sure, we all have pleasant visions of truly interactive ebooks driven by creatively built JS content. But in the real world, ads would be the first thing to be added if JS was supported.
If that's the case, you didn't have a genuine EPUB to start with. To meet the spec it needs to be in a container (a renamed ZIP file) and have a handful of related metadata and navigation files alongside it.
That said, the actual text of the book is done by HTML/CSS, but within the EPUB container file.
Isn't epub a zip file of a bunch of html docs, metadata and images?
No, why would I want Electron ??
IMHO EPUB should specifically be script-free.
And if I wanted scripts in my document¤, then instead of packaging the whole browser (that would be overkill!!) with the document like Electron does (?), I would rather use MHTML.
¤ The following was supposed to be my example, but since this website uses Flash, these scripts are no longer easily ran. But since they are described, you should have a good idea what they are going for :
http://resonanceswavesandfields.blogspot.com/2007/08/phasors...
Yeah maybe I am just knee jerking, with AV1. Broadly speaking however there would be two schools of image and video compression, one for computer generated images and one for images of natural concepts. So AV1 isn't really suited for animated graphs and the like at the end of the day.
On second thought maybe allowing in AV1 would open the door for sound, which really would take us to far away from the book format.
I do definitely see the need for having animations such as the ones you link in your post however. So many things that just takes sentence and sentence to describe can still be described way more efficiently with an animation.
CSS Animations or animated SVG maybe?
Yeah, animated SVGs would be even better for this use case - but you need raster graphics support too for other use cases (some animations might require the inclusion of photographs).
I don't see how sound support is an issue - no more than color and high frame rate support are issues for a format that might also end up displayed on grayscale only displays incapable of high framerates. It's up to the creator of the media to take these into account (or not).
I think that we should define a book as something that you can use only with your eyes.
If I bought a book and I would need to use headphones to "read" all the content in it I would feel a bit defrauded.
(Though a (sub?)format dedicated to "e-ink" readers might actually be a good idea ?)