iframe vs. native webview to host EPUB content documents (spine items) about architecture HOT 8 CLOSED

@winniequinn said:

I'm just starting to play with the idea of not using iframes at all. They cause issues with paged-x (at least on mobile), they can get in the way when using VoiceOver or TalkBack (as the browser sees the iframe as another container to be navigated into), et cetera.

The whole point of using an iframe, at least as far as I know, is to be able to maintain an outer container for the reading system with the iframe being responsible for holding the contents of the book. This certainly makes sense if the goal is to be able to move between different chapters of a book all within the browser as is presently the case with Readium.

At least on mobile though, I think another solution is possible. We could get rid of the iframe, make the browser responsible only for showing a single chapter, and then load up other chapters in different web views that are then swapped into view as appropriate by the application-layer code written in Java, Swift, et cetera. This approach would seem to eliminate the need for an iframe, would make precaching adjacent spine items very simple, and would allow more work to be lifted out of the land of JavaScript and brought into the application layer.

It may well be possible to use the same approach on the desktop as well. Electron has a web view component that presumably could be used to the same effect as WKWebKit and android.webkit.WebView. I need to look into this a bit further.

from architecture.

@rkwright replied:

@winniequinn This is not a bad idea (at all). Iframes are certainly not ideal. However, trying to put separate spine items in separate containers has been tried more than once. See the prefetch branch in shared-js. One of the major problems encountered is NOT playing audio and video (as well as scripting) before the web-view is "brought into view". Both EvidentPoint and Bluefire experimented with it, but were unable to resolve it satisfactorily. But YMMV... It WOULD be a good approach if the problems can be resolved.

from architecture.

@HadrienGardeur replied:

This feels like two separate discussions:

• what the reader/container is and how we inject CSS/JS
• how we handle navigation between spine items

I'm also in favour of either dropping the iframe or offering an alternative, as I've said before in #12 (comment)

How we actually handle different spine items is another question, probably worth having its own issue here.

from architecture.

@danielweck replied:

@winniequinn this is how other "i"-named reading systems do it.

In Readium-1 we have reader.html that effectively bootstraps the entire readium-shared-js subsystem (rendering engine), which lays out the EPUB content iframe hosts, and is responsible for injecting behaviours into spine items (Media Overlays, link hijacking, keyboard / input device intercept and forwarding, CSS styling, epubReadingSystem, MathJax, etc.).

Using native webviews instead of iframes would mean writing a large portion of the rendering code in native per-platform code, which I think is acceptable in the context of Readium-2.

Note that we did look into using Electron's special web frame, but this is basically an extended iframe with special features (still in the renderer process though).

from architecture.

Electron webframe:
https://github.com/electron/electron/blob/master/docs/api/web-frame.md

from architecture.

@danielweck
There's also this:
webview tag in electron
https://github.com/electron/electron/blob/master/docs/api/web-view-tag.md

from architecture.

Oh thanks! :)

from architecture.

Part of my comment at #12 (comment) is also relevant here:

3. Serving content

Ideally, I'd like each implementation to support the following things:

• expose a manifest in a format where a single document can contain all the information that we'll need (this covers metadata, spine, manifest and table of contents), which means that I can do a single request and cache it
• serve each resource in the publication in a way that doesn't require to rewrite links and URIs for images/audio/video/CSS/JS, which means that all paths will be relative to the manifest
• allow the ability to inject JS/CSS in HTML documents without using an iframe and injecting in JS (for example using query parameter such as GET /chapter1.html?js=paginate.js&css=paginate.css instead of a plain GET /chapter1.html) and expose this ability via a URI template in the manifest
• support media fragments, for example when I need to start audio/video at a specific timestamp
• serve a number of static resources that are useful (HTML reader, JS, CSS)

With all these, I think it would provide a lot of flexibility in what could be achieved by implementers:

• Reading System A can use the default implementation (currently reader.html + iframe)
• Reading System B decides instead that it would prefer to simply use our native implementation with its HTTP server + decryption, get the manifest (and cache it) and handle pagination and the rest itself (for example using the WKWebview APIs for pagination)
• Reading System C only streams EPUB files, and handles the HTTP part on their own server, but uses our JS to handle everything else in a native app with a Webview

from architecture.