Re: Web Publications via HTML Imports

There might be some opportunity from the Resource Hints spec (still a Working Draft...but already partly implemented):

https://www.w3.org/TR/resource-hints/


Resource Hints include `prefetch` and (most importantly to us) `prerender`.


In my head (right now), one interesting shape of a Web Publication is an authoritative Table of Contents document in HTML that (by the nature of it being a Web Publication) offers the following to a consuming browser/reader:

 - a "keep" (more or less analogous to "install" from ServiceWorkers) option that triggers this offline-ification

 - a prescribed process of pre-rendering the primary resources stated in the Web Publication's ToC

 - ...the process for which fetches/caches all secondary resources (as we've recently defined)


The Resource Hints spec is already defining the relationship with CORS, CSP, Single Origin, and the rest, so (my hope) is that the "plumbing" for this approach is already being built.


Our Web Publication spec would then reference the prerender/prefetch behavior to be enacted when a Web Publication document is "kept."


I'll try and rough some code/text up soon that (dis?)prooves this possibility--or at least gives us something more tangible to discuss. :)


Thanks, all!

Benjamin


--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Ivan Herman <ivan@w3.org>
Sent: Monday, July 31, 2017 5:25:18 AM
To: Dave Cramer
Cc: W3C Publishing Working Group
Subject: Re: Web Publications via HTML Imports

This is certainly a fascinating approach. And I believe we have to emphasize an aspect of the experimentation you did: the html import spec does _not_ mean that all content must be added to the DOM of the main document, this is just the way you implemented it in the embedded javascript.

What I am a bit worried about is (seeing all the discussion on github) what will happen to the css and javascripts that are referred to from the imported document. Your example is simple because, I presume, all chapters use the same style. However, if there are chapters that look different (which may be the case for more complex documents that are less homogeneous) then this may go wrong if the CSS files are not carefully drafted. Not impossible, but may make authoring a bit more tricky.

But it is definitely an approach we should keep in mind. Thanks…

Ivan




On 24 Jul 2017, at 05:31, Dave Cramer <dauwhe@gmail.com<mailto:dauwhe@gmail.com>> wrote:

I've been experimenting a bit with a different approach to creating web publications.

Our fundamental goal is figuring out how to treat a collection of web resources as a single entity. It's not hard to create a list of such resources--EPUB had the package, PWG has been talking about JSON manifests. But both those things just refer to the resources rather than including them, and both those things aren't HTML.

And it occured to me that this exact problem was solved twice in the XML document world, first with external entities and then with xinclude. And HTML has created just such a feature, in the form of HTML imports*.

A web publication can be represented by a single HTML document that includes other documents via html imports:

<link rel="import" href="chapter-1.html">
<link rel="import" href="chapter-2.html">

I've made a little example at:

 https://dauwhe.github.io/zero-labs/MobyDickImport/MobyDickImport.html
(see #2 below for why you should view using Chrome).

I see lots of advantages:

1. It's harder to argue about what the URL of the web publication is :)

2. It's easy to provide fallback behavior. If you view the above link in Chrome, you see the entire copy of the book, as Chrome supports HTML imports. If you view the link in Safari or Firefox, you see the book table of contents, so you can still access every resource. And yes, there's a polyfill for HTML imports.

3. The HTML file containing the imports provides a "canvas" for authors who wish to supply their own user interface, and also allows reading systems to just take the links.

4. Nested web publications become easy.
.
5. Resources can be shared between different web publications.

6. The master HTML file is a natural location for publication metadata, which can be expressed with all the richness and i18n support of HTML (and can also be embedded as JSON-LD, etc.

7. Web app manifests could still be used to provide save-to-homescreen, etc.


*Yes, HTML imports are controversial, and may evolve into a module system. Lots of interesting discussions at https://github.com/w3c/webcomponents/issues/645. Might be fun to talk to Web Platform WG folks about our use cases. Finally something fun to do on Friday at TPAC!

Dave









----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704