edrlab / bd-comics-manga

Study of the requirements and solutions for expressing digital bd, comics, manga, graphics novels ... using Web Publications and EPUB 4.
6 stars 5 forks source link

Building blocks #1

Open frank-actialuna opened 7 years ago

frank-actialuna commented 7 years ago

Requirements

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):

llemeurfr commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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