Is it Safe to Use height: 100vh?

[Slevin#7]

First let me say, many many thanks to you all for all the information you provide every single thread. It's a great pleasure to know that there is always something to discover I haven't had on my radar so far. Thus being said, I of course wanna take some time to try and see whether the one or the other tip might work, which will take some time - so please bear with me that some feedback will not come instantly (and family life wants also to be dealt with ).

Originally Posted by RbnJrg

You don't need page-breaks if you work under epub3; watch the attached epub. Try to increase/decrease the font-size to see what happens.

That would really be great, if it would work as expected. I've tried many different adaptions of your solution, but I couldn't get one of them working in PocketBook. I managed at least to get the image placed exactly at the point in text where it should be by removing "float: left" from the .picture element, since otherwise some reader just float the text dynamically around the page which holds the image.

The big issue, however, is that the image gets split over two pages in PocketBook:


If you have a solution for that I would really consider taking your code, since I think dynamic break-points are better than hard-coded page-breaks.

Originally Posted by KevinH

For the record, which true epub3 ereaders do not support even basic javascript?

Afaik, none of the major commercial reading applications like Google Play Books or Apple Books support JS for security reasons.

Originally Posted by RbnJrg

By the way, the OP could try using not only "vh" but also "svh" or "dvh" (for example, Sigil and its plugins, Thorium, Calibre Viewer, accept those units). Regarding units viewport there are much more than vh and wh:

https://www.terluinwebdesign.nl/en/b...h-svw-lvw-dvw/

https://caniuse.com/?search=svh

These new sv* units are especially useful for Android and iOS e-readers. One could try a style with:

.myHeight {
   height: 100vh;
}

@supports (height: 100svh) {
   .myHeight {
      height: 100svh;
   }
}

Yes, I've already forgotten that there are new units. I've used them years ago the last time I made a webapp for smartphones, but that's far away and thus far out of my recollection^^. Thanks for bringing this up. I've already tested them in different ways and my current conclusion: vh followed by svh works well, while dvh seems to mess up some of the reader.

Again, thanks for all this valuable insights - and if RbnJrg would have any suggestions how to fix the splitting issue, I'd really be happy - at least until the next challenge shows up...

[KevinH]

Originally Posted by Slevin#7

Afaik, none of the major commercial reading applications like Google Play Books or Apple Books support JS for security reasons.

Apple Books does support Javascript in epub3 and has since Apple Books 1.5.

Books with JavaScript Interactivity
Overview
Interactive content is supported for both flowing books and fixed-layout books. This section provides information and tips for creating interactivity using JavaScript. EPUBs with JavaScript interactivity require Apple Books 1.5.

Google Play does not support javascript, or mathml or multi-column layouts and other sections in the nav besides the toc. That is quite a list of unsupported features. Seems like someone is trying to get by with an epub2 level rendering engine.

I would not consider Google Play epub3 compliant at all as it seems to skip too many of the specs features.

Again real epub3 e-readers typically use web engines like webkit, or blink (electron, Readium) which are all javascript and C++/C based and can therefore easily use javascript both internally and support its use in epub.

That is why it is so rare to find a real epub3 e-reader that does not support basic javascript.

Not sure what is up with Google Play as even Chrome's blink supports javascript, mathml, multi-column, etc. Sigil's QtWebEngine is a Chrome blink web engine. So natively Google Play should support anything Sigil does unless it was split off from development long ago.


Perhaps Google Play uses a really old engine?

[RbnJrg]

Originally Posted by Slevin#7

That would really be great, if it would work as expected...

Well, I don't know what can it go wrong with your PocketBook. In my PB for Android all works fine:



Don't remove the property "float: left", that is one of the key of dynamic break-points. Try with the epub I attach below; it's the same as the prevoius one but with a bit more of text.

Afaik, none of the major commercial reading applications like Google Play Books or Apple Books support JS for security reasons.

Google Play Books is not an epub3 ereader but an epub2 one with supports for some css3 properties.

Again, thanks for all this valuable insights - and if RbnJrg would have any suggestions how to fix the splitting issue, I'd really be happy - at least until the next challenge shows up...

Try the epub below, that as I said, it works fine in my PocketBook.

[Slevin#7]

Originally Posted by RbnJrg

Well, I don't know what can it go wrong with your PocketBook. In my PB for Android all works fine:

Thanks again, I've tried your new upload as well, but still the same issue - seems to be an Apple problem ;(

However, since the majority of our members work with Apple devices I'll have to take this as the least common denominator. GPB and Apple Books work fine - with some minor flaws in Apple Books regarding background colors when the dark theme is active.

@KevinH:
Many thanks for this valuable information about Apple Books and Google Play.

To bring my topic question to a conclusion I will say, that it seems to be safe to use 100vh, but with your suggestions I have added the svh unit as well without any troubles. Also, thanks to RbnJrg's CSS in his provided ebook, I found out that adding the overflow property to the container where the height property is set will force Thorium to render the page properly as expected. So here is the final HTML and CSS I'm currently using:

HTML:

<div class="single-page v-center">
  <figure>
    <img src="../images/aloha.png"/>
  </figure>
</div>

CSS:

.single-page {
  -webkit-column-break-before: always;
            page-break-before: always;
                 break-before: always;
   -webkit-column-break-after: always;
             page-break-after: always;
                  break-after: always;
}

.single-page.v-center {
  display: flex;
  justify-content: center;
  align-items: center;
  /** Some reader may have trouble to render page dimensions properly with the
    * result in inserting a blank page directly after. PocketBook is one of
    * those candiates. The issue seems to to occur randomly, especially on
    * recalculation after device rotation or changing the font size. For the
    * time being, the only real working solution is to wave and smile... */
  height: 100vh;
  height: 100svh;
  max-height: 100%; /* better safe than sorry */
  /** Though some readers like Thorium place the image on a separate page, they
    * calculate the distance of the height from the actual text position, which
    * results in the subsequent text being placed on the image-page behind the
    * image itself. overflow: hidden seems to tackle this issue. */
  overflow: hidden !important;
}

/* crucial to not overlap following text by the image */
.single-page img {
  /* match .single-page.v-center height */
  max-height: 100vh;
  max-height: 100svh;
}

Thanks for all your help - I'm pretty sure I can come up with another question in decent time