epub-fetch module treatment of css ressources

[patt0]

Firstly thank you.

I have been integrating readium.js into our mobile viewer project for a a few months now ( I am aware of the mobile started packs ) in a html5 strategy ( crazy I know ) and have come to a fairly stable alpha build of our product.

I wonder if the treatment of CSS files as part of epubFetch.resolveInternalPackageResources is proper. Indeed it treats most if not all of these as blobs, and while this is true for most internal ressources, it seems to me that we should deal with the css ressources as text and load them as such.

The behaviour that I have been observing on mobile browsers (iOS and Android) using the codova Web View is that the css does not seem to be loaded ( in time? ) before th rendering. And while this behaviour does not affect us on Chrome, I wonder if this is an oversight or by design.

When I download the epub and unzip it in the HTML File system using plain package exploder, the css is loaded and the epub renders properly.

[aadamowski]

Hi!

We're planning significant changes to these areas of code in near term, so we could have a shot at fixing this.

Yes, it's true that non-binary assets like stylesheets should probably be fetched as text. I am unsure what's the proper approach if they are non-ASCII (using @charset rule) - that would need to be tested.

Do you have a simple isolated testcase (like a really small PhoneGap app) that would demonstrate this issue on Android and iOS? It's hard to work on a fix without a reproducible test case.

[patt0]

I'll work to build a small app to reproduce this and move to get it out to you ASAP

[danielweck]

programmatic fetching has undergone significant improvements since this issue was posted, please rebase tests against the latest code and do not hesitate to post a new issue if necessary. Closing this one now.