Re: [w3ctag/design-reviews] Audiobooks (#345)

Really hoping to see @w3c/strategy#171 advance, reading this part of the spec on Web Packaging:

> The Working Group is very interested in Web Packaging as a future option for Audiobooks (and other web publications), but due to timing, we have decided to proceed with a temporary option in the Lightweight Packaging Format (https://w3c.github.io/pwpub/), until there is a viable web option.

This audiobook spec includes a manifest.json, which among other things enumerates all the files & includes some metadata. This is a good thing for the future, because I don't believe there's any API as a part of Web Package or otherwise that a page can use to discover other bundled content.

In a webpackaging world, I feel like some adjustment to the manifest would be required. If the manifest refers to filenames, is it up to the browsing context to figure out what URL the manifest was at, and to join the paths together? Alternatively, the manifest could include canonicallized full urls, rather than filenames or paths, as these would be how the resources identify themselves inside the bundle.

Venturing further afield, the web's inability to observe available resources is also present in fetch, which won't tell you that, if you fetch a resource, that other resources are being PUSHed in reply to that fetch ( whatwg/fetch#65). In general, approaches to "audiobook" might be different if, when a bundle is loaded, or resources are pushed at the page, the page had some means to detect those resources which it now "has".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/345#issuecomment-513967298