javascript in epub

[Quoth]

Originally Posted by Slevin#7

IFor example educational books with Q&A sections, interactive storylines, escape stories, science texts, etc etc.

An app is easier and more likely to work and easier to distribute for those. Once you have used the framework once different content is easy to swap for titles of the same functionality.

Science texts can certainly be done with zero javascript but benefit from epub3 reflowable as a more flexible alternate to PDF. PDF is better for fixed layout.

[RbnJrg]

Originally Posted by Slevin#7

I agree that for most pure fiction stories EPUB2 is sufficient. But there are many other scopes where full EPUB3 functionality inlcluding JS would have great benefit

Yes, it is true that if the design is not very demanding, CSS2 may be sufficient in many cases, but epubs should still be epub3 (even if they only use CSS2). If the device accepts CSS3 and you're only providing CSS2, then the users are receiving a reading experience inferior to what they can expect.

That's why all epubs should be epub3 (since they can be opened by devices that only support epub2), containing the best code available for modern devices and fallback code for older ones. This way, users with modern e-readers will get the best out of them, and users with older e-readers will still get a satisfactory, but not optimal, reading experience.

And even novels and fiction books, without demanding design, can benefit from JavaScript. How? In many of my comments, I've affirmed the convenience of having the following property declared in the stylesheet:

body {
font-size: 1em;
}

With this, all the dimensions of the other elements set to "em" are referenced to that size defined in body. So if at any point, in body, instead of "font-size: 1em" we have "font-size: 0.8em", ALL the elements of the epub set to "em" will reduce their size (it would happen the other way around if the font-size increases). And where does JavaScript intervene? Well, it's very easy with JavaScript to determine the height and width of the viewport, know the available space (we'll know if the epub was opened on a large, medium, or small screen), and thus set an appropriate font size. This way, if the script detects a large screen, it does nothing, but if it detects a small screen, it overwrites the font-size value for body in the stylesheet to, for example, 0.8em. And with just this, all the values set to "em" in the epub are reduced. Of course, this don't negate the users' ability to set the font size they prefer, but it does provide a starting point, a point of comparison, to see how the epub looks with the optimal font size based on the detected screen size.

There are also other uses of JavaScript for fiction epubs that greatly improve the layout (for example, preventing text from overflowing in a block regardless of the user-defined font size; the text will always remain adjusted to the block size). And of course, adding hyphenation on devices that don't natively support this feature. This topic was recently discussed on the Sigil forum, when I asked Kevin if he could enable the Fetch API so that the Hyphenopoly script could also work in Sigil.

[DNSB]

Originally Posted by KevinH

Epub2 is dead as a spec. Amazon is not king. And Javascript when used intelligently can be useful. Perhaps it is time to let the past go.

I agree that ePub2 is no longer a consideration.

However, I would have to disagree that Amazon is not king for commercial ebooks. For the authors, I do work for, even those who have gone wide, the majority of their income is from Amazon. For that reason, I can not and will not consider adding Javascript for any purpose where it's lack would be noticed. I will have to admit Kindle take down notices were responsible for a fair chunk of my early ebook cleanup jobs and a couple of those were due to ePub3 ebooks that used JavaScript.

For my personal use, I can go wild on using advanced features but for commercial work, KISS is definitely the only way to go. I do use a mix of ePub2 and ePub3 code but that is as far as I go at this time.

[RbnJrg]

Originally Posted by DNSB

I agree that ePub2 is no longer a consideration.

However, I would have to disagree that Amazon is not king for commercial ebooks. For the authors, I do work for, even those who have gone wide, the majority of their income is from Amazon. For that reason, I can not and will not consider adding Javascript for any purpose where it's lack would be noticed. I will have to admit Kindle take down notices were responsible for a fair chunk of my early ebook cleanup jobs and a couple of those were due to ePub3 ebooks that used JavaScript.

For my personal use, I can go wild on using advanced features but for commercial work, KISS is definitely the only way to go. I do use a mix of ePub2 and ePub3 code but that is as far as I go at this time.

I think since this is the epub forum, we shouldn't speak about Amazon here, because the epub destined to be a .azw3 or .KFX format is another kind of epub. But of course, those epubs can't have js (and many others css3 properties).

[DNSB]

Originally Posted by RbnJrg

I think since this is the epub forum, we shouldn't speak about Amazon here, because the epub destined to be a .azw3 or .KFX format is another kind of epub. But of course, those epubs can't have js (and many others css3 properties).

Not sure if I would call it another kind of ePub but different restrictions. OTOH, I remember at one point generating separate ePubs for Amazon KDP, B&N Nook and Kobo for a couple of authors. I have no real wish to revisit those days unless there was some compelling reason to do so.

[Doitsu]

Originally Posted by Quoth

Once you add animation or interaction or video or sound, it's no longer a book. It's best done as an app and not pretending to be a book.

Creating an app instead of an epub with JavaScript is overkill. Moreover, you'd have to maintain code bases for all supported platforms.

While most reflowable fiction epubs usually don't benefit much from JavaScript, except for adding hyphenation, JavaScript can be very useful for non-fiction books, in particular textbooks.

Years ago I saw an example of an electronics textbook that contained a formula whose values could be changed.

I created a similar example that illustrates a physics formula.
(It works fine with Thorium and ADE 4.5.)

If you wanted to do this with a static epub, you'd have to add at least 4 images to illustrate how changes to the input values affect the result.

JavaScript might also be useful for other kinds of textbooks. For example, you can use it to show/hide interlinear text.

Just because you haven't seen commercial books that use JavaScript, you shouldn't flat-out deny its usefulness or keep insisting that apps are the only way to go!

[Quoth]

Oh I have seen commercial ebooks using javascript.

Also stupid fixed layout epub3 that is more awkward than PDF. However that's nothing to do with javascript.


It may make sense to use javascript in epub3, but really creation and maintenance in the long term is no better than an app and app distribution will work to more users.

I'd like to see a reflowable epub version where footnotes don't need clicked, don't popup, and render on the same page as the source, like changing page size on the word processor. Also that no hand-coding is needed. Just a docx import. The epub2 should have had it.

1. Epub was developed for novels.

2. A mistake Web people taking over the spec prior to epub 3 as they were bound to add loads of stuff to try and compete with PDFs and apps, but lose sight of what books need.

I look forward to an epub4 with clear versions/indication of kind of thing the file is.