Closed danielweck closed 5 years ago
Insightful comments by @JayPanoz starting here: https://github.com/readium/r2-navigator-js/issues/18#issuecomment-444148032
As regards âpossibly relatedâ.
iframe
, you can for exemple set an explicit height
and all of a sudden, 100vh
can become 15000px
instead of being the browserâs windowâs 860px
because itâs the height of the iframe
that counts for the viewport in the EPUB styling context. I can confirm that is something that shouldnât happen when using web views.So to sum up, this issue can be scoped to the additional margin weâre setting up in scroll mode.
Thanks for opening this issue BTW. đ
I can confirm that is something that shouldnât happen when using web views.
:)
...well, unless the said "web view" is Electron's own interpretation/implementation (derived from Chromium webview) which is in fact an embedded object (custom element + shadow DOM) that emulates a sandboxed iframe (isolated in a separate process), so vh
and vw
may in fact apply (to be honest, I haven't checked thoroughly).
See:
https://electronjs.org/docs/api/webview-tag
... I know, there is an alarming disclaimer at the top, but readium-desktop
, r2-testapp-js
and of course r2-navigator-js
all build on top of Electron 1.*
which isn't so deprecating about webview
:
https://github.com/electron/electron/blob/v1.8.8/docs/api/webview-tag.md
We are tracking this problem for later:
https://github.com/readium/r2-navigator-js/issues/15
Right, Iâll follow up tomorrow as Iâm quite frankly exhausted right now and some comments may appear passive-agressive â sorry about that, wasnât my intention â but weâd better have a solid reason for changing how that works, especially as itâs in the 2017 CSS snapshot, on which EPUB 3.2 is now relying â and well, if Iâm being honest and although Iâm trying really hard to be neutral, itâs very difficult to not be on some kind of a mission as I personally saw the nicest and most talented people quit ebooks because ebooks break such standards and they couldnât take it anymore.
For vw
(viewport width) Iâm totally cool saying âHey, donât count on that, itâs not compatible with CSS multicol, that weâre using for pagination.â For vh
though, Iâm super reluctant, as this is quite possibly the only way out for styling covers as far as authors are concerned â and weâre also using that actually, in multiple places â and spoiler alert: authors are primarily writing their styles for pagination, most wonât even test their ebooks in scroll.
At first I thought it would maybe impact scroll-continuous
, but this isnât necessarily the case â and the scope may be well wider. So Iâll take a look tomorrow, thanks for the links BTW.
That + some vendors advise vh
actually so people are already following those guidelines.
In Flowing EPUB books, it is recommended to size images using viewport units to maintain adaptability for various screen sizes.
Source: https://help.apple.com/itc/booksassetguide/#/itca71ad3c33
But then again, note the primary issue is about adding a margin-top
and margin-bottom
in scroll mode so that text content is not âglued to the edgesâ of the RS there.
Works for text but not for files consisting of images only. So Iâd really like to scope this issue to that and see what our options are â not so much using CSS only unfortunately, but itâs worth discussing imho.
Alright, hereâs an illustrated recap on scroll styling.
So right now, we have the following box model for body
:
Donât pay attention to horizontal margins (372
, we actually donât set this one, our value is auto
). Other than that:
body
has vertical margins of var(--RS__pageGutter)
so 50px
here ;body
has horizontal padding of var(--RS__pageGutter)
so 50px
too;540px
wide.But why did we set vertical margins?
It was all about text.
Note: In the following screenshots, orange (outer) is body
âs margins, green (in-between) is body
âs padding, and blue (inner) is âcontent containerâ (div
, figure
, etc.)
For instance, hereâs a chapter without any margin-/padding-top
.
I can recall a heading in our test files that was somehow partly hidden at the top of the chapter because we didnât apply any margin. I canât remember why exactly (maybe negative margin-top
, relative
positioning, or the iOS navbar hiding part of it only in the scroll view) but we added that as some sort of safeguard so that it canât happen.
And same for the bottom of chapters.
Without a margin
With a margin
So the idea was to give some extra vertical spacing for content to breathe.
Letâs now look at images (e.g. cover).
Without a margin (note we constrain the height to 95vh
(so 95%
of the viewportâs height so that we donât accidentally create blank pages in the paged view).
With a margin
I can confirm thereâs overflow in this last screenshot, although you canât see the scrollbar (because MacOS is buggy). But now the height of the document is the height of the image (95vh
) + the margins (50px * 2
) so it is obviously overflowing.
This is obviously something we donât want, we want no extra vertical margins there.
What the issue is
In CSS, you canât conditionally apply margins depending on the documentâs content (text vs. only one image). I indeed canât use such logic:
if body has only an image
then remove margin-top and -bottom from body
Because when checking this image, Iâm already getting out of body
âs scope, Iâm further down the DOM (the image
) and I canât âbubble upâ i.e. styling its parent elements.
All I can do is expecting some kind of flag, so in ReadiumCSS by default, a custom property such as style="--RS__imgOnly: true"
either on html
or body
e.g.
:root[style*="--RS__imgOnly: true"] body {
margin-top: 0;
margin-bottom: 0;
}
/* Note that could be [style*="--RS__imgOnly: false"] but since `--RS__imgOnly` is a boolean, no need to use it */
:root body {
margin-top: var(--RS__pageGutter); /* 50px */
margin-bottom: var(--RS__pageGutter); /* 50px */
}
So all we can do with vanilla CSS is either applying vertical margins to all documents or not applying them.
Hypothetical fixes
Such logic is JS territory, either in the form of:
:has()
(CSS pseudo-class) polyfill â but brace yourself for the handling of all author markups possible;html
or body
, and that I can use in CSS to target body
(could also be parser and not JS at runtime per se).Related: scrolled-continuous
rendition e.g. how will it be implemented, will it break vh
, how to make a clear distinction between files, etc.?
After further reflection, Iâm wondering whether rolling back to no vertical margins and letting the app handle those, as in the paged view, wouldnât be the most reasonable call. That would enforce consistency for implementers, which in my opinion is most important.
I have observed a similar stretching of cover image issue with ebook. The cover image is rendered from start.html and since it is provided by the publisher it can have different html and css properties. For example i am showing below the html of two ebooks where in first book the cover image rendered perfectly but in other it gets stretched to multiple pages.
HTML in start.html where cover image does not stretch.
<body style="margin:0.00em; text-align:center;">
<p class="cover" style="text-align:center;"><img style="height: 100%;" src="9780857633446_cover_epub.jpg" alt=""/></p>
</body>
Cover image is stretch in this book
<body style="margin-top:0px; margin-left: 0px; margin-right: 0px; margin-bottom: 0px; text-align: center; background-color: #ffffff;">
<div><img src="docimages/cover_ader.jpg" alt="cover" style="height: 100%" /></div>
</body>
Apparently we have observed this issue when migrated to recent readium-sdk along with LCP. In the previous setup which was using 2-3 yr old readium this problem was not so much evident.
We are using readium on android & IOS platform.
Is there any easy fix for this ?
Thanks
we have observed this issue when migrated to recent readium-sdk
Just to be clear: you mean Readium2, where ReadiumCSS is used to apply document formatting, right? (I am asking just in case you use a hybrid Readium1 + ReadiumCSS solution)
We are using Readium1 from this branch : https://github.com/readium/readium-sdk/tree/feature/latest-working-build-config/Platform/Android
Oh, so you are not using ReadiumCSS, right?
For Readium1, please report in readium-shared-js
, e.g.
https://github.com/readium/readium-shared-js/issues/342
(the image handling code in Readium1 SDK has not changed for months/years, but your migration from a very old revision of Readium1 may indeed have introduced different behaviours / regression bugs)
Yes we are not using ReadiumCSS in the current setup. Also we were not using it earlier. In asset folder there are some css file present such as SDK.css etc.. I believe readiumCSS is applicable only to readium 2 and onward, right?
Thanks i will report in readium-shared-js project.
So yeah, readiumCSS is applicable to r2 onwards.
Note we have a list of CSS-related issues from r1 that this project is attempting to fix in the wiki: https://github.com/readium/readium-css/wiki/CSS-related-issues-in-Readium-1 â uncrossed items donât necessarily mean we havenât fixed it, maybe it doesnât apply, or we havenât had the opportunity to address it yet, etc.
cc @danielweck Removed those vertical margins in develop
branch. Please let me know if this fix the overflow: scroll issue for covers.
Thanks Jiminy, I've merged your updates into the ReadiumCSS copy of r2-navigator-js
:
https://github.com/readium/r2-navigator-js/commit/4d956424ddaa4eec6c52516176c1deeb7f66dc80
Test with Metropolis (which I found in your screenshots https://github.com/readium/r2-navigator-js/issues/18#issuecomment-444162879 ), from Feedbooks: http://www.feedbooks.com/book/1123/metropolis
Load the remote EPUB directly in r2-testapp-js
using the command line: npm run electron http://www.feedbooks.com/book/1123.epub
.
Cover and text in paginated mode (CSS columns):
Cover and text in scroll mode:
As you can see, no extraneous scroll extent, thanks to the removed top/bottom margins in ReadiumCSS.
No problem, and thanks for the confirmation.
Will resolve this issue when merging this change.
Fixed via #63
Issue originally discussed at: https://github.com/readium/r2-navigator-js/issues/18