-
Notifications
You must be signed in to change notification settings - Fork 16
Rendering
A common request for reflowable EPUBs is for images to "bleed"—extend to the edge of the screen, analogous to how images in print can extend to the very edge of the paper. This is possible in FXL EPUBs, where content is absolutely positions, and reading systems historically haven't reserved as much space for reading system "chrome".
A few use cases could be supported simply by mixing FXL and reflowable content in the same EPUB, which is allowed by the specs. Most reading systems don't support this. But many more use cases involve images in reflowable EPUBs.
Designing such a feature is quite complicated, because we're asking that our content display in space that's historically been reserved to the reading system. Would bleeding images obscure reading system controls?
Even the technical design of such a feature is not obvious. We're asking images to be positioned at the top or bottom of a page, which is defined in the (unimplemented) CSS Page Floats spec. This seems like a good starting point, although the spec currently doesn't support floating to page corners (top+left). But the "bleed" aspect isn't necessarily a good fit for CSS, given that this isn't an issue for the larger web platform. In some ways it's like a processing instruction, but those don't seem to have survived the transition from SGML to HTML. Custom attribute, perhaps? It's reminiscent of the ```display-mode`` member of the Web Application Manifest spec, but we need much more granular control. Are we actually asking that the image be displayed relative to the top-level browsing context?
Implementation would be challenging, as well. EPUB reading systems typically display author content inside a div or frame, with unknown styling applied both outside and inside the frame.
<div class="image full-page">
<img src="images/foo.jpg" alt="A great image! Tremendous!"/>
</div>.full-page {
float: block-start;
height: 100vh;
-epub-bleed: all;
}-epub-bleed ( block-start | block-end | inline-start | inline-end | all )- Full-page image, extends to the edge of the screen on all four sides.
- what happens when the image doesn't exactly fit the screen? Aspect ratio must be preserved (always?)
- controls for both vertical and horizontal alignment?
- control over background color for where image doesn't fit?
- just set image height to 100vh?
- idea of page float necessary for text to continue normally before/after image; otherwise there could be huge gaps before image
- what happens if epub is set to flow-scrolled-continuous (either by opf or user choice)
- would there be text on top of such an image? what happens if such text overflows?
- clarity is needed between the use of 'screen' and the webview. Typically these match on mobile devices, but would not in a desktop reading system that is windowed (but could go to a 'full screen' mode)
epub standard protocol for footnotes/endnotes [with return anchor link], which allow for a11y and styling across the footnote text. ibooks completely breaks this but even Readium doesn’t really offer a comprehensive solution.
- CSS spec implemented by Prince and AntennaHouse but not browsers
Include marginalia [notes] as part of the EPUB3 standard for reading systems to implement
(placeholder for interoperable, accessible solution. The pressure is on, Benetech! 😀)
The same content looks different in different reading systems. Styles created by the author are often overridden. Users need control over the styling of their own books. How do we make the ecosystem more interoperable and more predictable?
- suggested UA stylesheet?
- metadata to request that RS not override ebook styles?
- place restrictions on author styles?:
- no author styles for html and body elements?
- no !important in author CSS?
- best practices for units (a common problem is for margins in ems causing massive problems on small screens)
- what about resets and frameworks like Blitz
- help for reader preferences from COGA personalization efforts in W3C?