search

w3c / epub-specs

Shared workspace for EPUB 3 specifications.
Other
305 stars 60 forks source link

Consider a mechanism such as "play order" for Fixed Layout publications #2664

Open GeorgeKerscher opened 2 weeks ago

GeorgeKerscher commented 2 weeks ago

In the DAISY 3 Standard, ANSI/NISO Z39.86, we had to resolve a problem with the proper sequence of content. I believe there is a similar problem with fixed layout publications.

The idea would be to establish a structure that identifies the correct sequence to present the information. A few could be chosen that presents an alternative to something in the fixed layout that is an equivalent representation of that portion of the fixed layout version. It should then be easy to toggle from the fixed layout view to the alternative version and maintain the position in both views.

From the DAISY 3 Standard we have:

8.4.3 playOrder Attribute (This section is normative.) The playOrder attribute is required on each pageTarget, navTarget and navPoint. It provides a means to collate all pageTargets, navTargets, and navPoints into a single ordered sequence that reflects their order in the normal playback sequence of the book as presented in the spine and SMIL file(s). playOrder is a positive integer; the first playOrder value in a document shall be 1. When the content elements of any pageTargets, navTargets, or navPoints reference the same SMIL time container, they must have the same playOrder value. playOrder must increase by one for each unique SMIL time container referenced by any pageTarget, navTarget or navPoint.## Issue on the EPUB 3.3 Recommendation

gregoriopellegrino commented 2 weeks ago

Interesting solution to explore.

I think in the context of Fixed Layouts done with HTML and CSS, perhaps DOM order and CSS (z-index) can suffice to fix the visual presentation.

The challenge is when the reading order goes from one page to the one next to it and then back to the previous page... In this case defining a read order above the DOM order would make sense.

I think we should find a solution that works natively with browser rendering engines, otherwise I see complicated integration with assistive technologies and reading applications.

mattgarrish commented 2 weeks ago

I think we should find a solution that works natively with browser rendering engines

The closest we have is aria-flowto, but it's limited to elements within the current document. We might want to work with that group to allow cross-document references, or to define something like an aria-flowacross for this case.

The web doesn't have a concept of spreads, so reading across two visible viewports is not a use case I expect they'd have considered.