Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop the default reading order from WP #302

Closed
murata2makoto opened this issue Aug 13, 2018 · 9 comments
Closed

Drop the default reading order from WP #302

murata2makoto opened this issue Aug 13, 2018 · 9 comments

Comments

@murata2makoto
Copy link

murata2makoto commented Aug 13, 2018

For the complete synergy of the OWP and Web Publications, I propose to drop the default reading order. A WP should always have the primary entry page, and it represents the "default reading order". Spine/itemref has lead to EPUB-specific mechanisms doubtful in the context of OWP. (See #207 )

I understand that people would like to wrap more than one HTML page as a single WP. But the right approach for WP is to enhance HTML for doing so. The addition of transclusion might be a possibility for using an HTML document as a spine.

@laudrain
Copy link

The addition of transclusion might be a possibility for using an HTML document as a spine.

@murata2makoto would you mind to give a sample?

@murata2makoto
Copy link
Author

Transclusion is a very old idea, but HTML does not support it well.

https://en.wikipedia.org/wiki/Transclusion

@llemeurfr
Copy link
Contributor

llemeurfr commented Aug 13, 2018 via email

@murata2makoto
Copy link
Author

murata2makoto commented Aug 13, 2018

@llemeurfr

XLink is another failure. HyTime is yet another failure. Nevertheless, I think that committing to spine/itemref implies a fundamental departure from the OWP.

@GarthConboy
Copy link
Contributor

Hmmm... hate to disagree with Makoto... but in my mind, it's the default reading order that really defines a WP. So I don't view this suggestion favorably! :-)

Though, I guess there is tension between what we want a WP to be (with RS backing, or with eventual UA support) and the current "classic" OWP.

@BigBlueHat
Copy link
Member

@murata2makoto fwiw, this approach of an HTML "binding document" (i.e. using transclusion or something like it to build the publication "out of" a single document) has been proposed here before and seems to have growing re-interest (see #271) as it moves the "binding" (or spine) into the accessibility tree of the entry page.

Here are a couple demos:

  • https://wileylabs.github.io/no-can-transclude/carol/
    • uses iframes for loading constituent resources
    • uses the fragment identifier of each iframe + CSS's :target to present the content
    • uses no JavaScript
  • https://wileylabs.github.io/no-can-transclude/moby-dick-from-epub-samples/
    • this is the [Moby-Dick from the EPUB3 samples
      (https://github.com/IDPF/epub3-samples/tree/master/30/moby-dick) with minimal changes made
    • the nav.xhtml was renamed to index.html and only the OPS directory is "hosted"
    • a JS-based "reader" is loaded to provide the current chapter/item displayed as an overlay + next/prev navigation (based out of the ToC)
    • this only (currently) works in Chrome because of the use of the <dialog> element, but it's perfectly navigable as a set of normal Web pages in Firefox (etc).

Lastly, there is also growing interest around adding an include tag to HTML:
whatwg/html#2791

Most of the concerns/discussion there center around adding irregularly shaped HTML fragments into a single render tree, and perhaps we could propose some specific solutions for those problems or further inform those use cases.

@murata2makoto
Copy link
Author

@BigBlueHat Thanks. This is very helpful.

Mechanisms around the spine of EPUB 3 are problematic. We sometimes create a synthesized spread from two HTML documents. RSs compute the current page number by adding the page numbers of preceding HTML documents. The next page button of RSs may visit the next HTML document. The srolled-continuous property value concatenates multiple HTML files. I think that requirements covered by these back-handed mechanisms should be covered by the OWP.

@murata2makoto
Copy link
Author

I overlooked "propose closing". Why should this fundamental question be closed without any discussions?

@wareid
Copy link

wareid commented Mar 13, 2019

Hi Makoto,

We discussed this issue today in the chairs call and reviewed the discussion in the issue. It's not been raised in a meeting, and with the way WP is designed today, reading order has been agreed upon by the group as the best way to move forward.

If you disagree, it would be a big help to provide us with use cases we can look at to confirm whether we need to reexamine this. Should this be the case, please feel free to open a new issue with the information!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants