Building blocks

[frank-actialuna]

Requirements

• declarative file format (no code)
• easy to implement in native code (iOS, Android) and HTML/JS
• based upon formats defined for Readium 2
• can represent rich contents (Phallainas, Homme Volcan...)
• must support two distribution modes:
  • downloading: data is delivered in standalone packages (zip files),
  • streaming: data is served piecemeal over the network.

Building blocks

In order to meet the requirements, we need to define these building blocks (or to make sure they are already part of the proposed ePub format):

• large images
• transitions/animations
• parallax

[llemeurfr]

I wonder if a declarative file format is the only proper way to go. The declarative features of EPUB 3 (epub:trigger, epub:switch) were never implemented and were finally deprecated in EPUB 3.1. On web, CSS and JS are kings: we won't be able to impose to the market any declarative markup for inclusion inside HTML5 markup.

We could create some declarative markup in xml or json, something like SMIL as used for mediaa overlays (i.e. external to the HTML markup), but to have it implemented in authoring tools may be difficult, such structure must be closely associated with the HTML markup and a reference CSS/JS translation of such markup will be required anyhow.

Shouldn't we instead propose a direct CSS/JS reference framework and use vanilla HTML5 markup for expressing what is needed?

I know this is not the "standard" way to standardize (it's more like creating a jquery or angular framework), but it may the the good way to have our work globally adopted, at least for some aspects of our work.

[HadrienGardeur]

@llemeurfr I think you're assuming that HTML will be the building block for WP/PWP, which based on my understanding is absolutely not the case for most dedicated reading apps.

[llemeurfr]

You're right to point at that fact. In WP/EPUB 4, we want images to be first class citizens. I'm questioning the "declarative file format" requirement vs a JS approach (or an hybrid approach). The fact that "spine items" may be pure images does not got in the way of this question IMO.

[HadrienGardeur]

Well a JS/CSS approach is mostly relevant for HTML documents in the spine.

We could of course have a JS based solution for it in R2, but that's different from saying that content producers should write their own JS/CSS per publication.

[franklefebvre]

We should not force native readers to include a web view. Therefore I don't think using JS for rendering would be a good idea. As for a purely declarative approach: there may be some cases where it would not be sufficient or practical (e.g. non-linear animation curves). In these cases maybe JS would make an interesting option, provided that all JS functions in the document are stateless and free of side effets, making it possible to call them with a non-web JS engine.

[llemeurfr]

The WG members agree that a declarative approach has many advantages over a programmatic approach, especially:

• simplicity
• performance
• security We don't want to reproduce the Flash history, with its actionscript language. Therefore we'll keep a pure declarative approach.