How can I set full-screen background image

[ClassWizard]

There are two questions:
I try to set full-screen background image to each page of one chapter and the cover page. To do so, I set the Navigator full-screen, then the top bar and bottom bar just cover the Navigator. The first question is how to set the top/bottom margin of each page, since the top/bottom line of text is covered by the top/bottom bar content. Another question is about the background image. I use the css style "background-repeat: repeat-y;". It work well in Android with Readium SDK, but not work in iOS with R2.

[ClassWizard]

About the second question, I have found the solution. Using "background-repeat: repeat-x;" and "background-size: 100vw 100vh;

[llemeurfr]

I had a feed back from Jiminy, the author of Readium CSS. I suggested that such modification should better be done at the app level, to avoid any clash with the author CSS on viewport height value.

[JayPanoz]

Hi, Readium CSS maintainer there.

I’m not sure how you’re applying the background image but assume it is set in the DOM itself considering you’re using CSS?

A little bit of history about the top/bottom margins for the web view: we had to do it this way because we could not add padding-top and padding-bottom for the html element in the web view itself. We indeed have to take the vh unit into account and adding such padding could have messed up some publications in significant ways.

The preferred method would be setting the background-image at the app level, and make the web view transparent (you might need to set a transparent background for html in the DOM though), see this StackOverflow question.

[JayPanoz]

Also, on a related note, we discussed an API to size and inject the content of your choice in those header/footer last week. You might want to pay attention to this API as it may create some issues when it ships, if you choose to keep your current solution – which would be reasonable if you control the input and know there is no vh value to deal with (or sanitized it beforehand).

[ClassWizard]

Thanks @JayPanoz @llemeurfr
I'm not familiar with css. In my case(iOS App, WKWebView), I modified the ReadiumCSS-after.css file. The :root selector, top: 10vh,height:80vh, and its original value is 100vh. I use 10vh to be the top and bottom margin. It seems to be fine, but still has another problem that the background image of the first page has shifted some pixels down. If I set the column-width to auto, the background image's offset is gone. But it switches to vertical scrolling mode. I'm not sure about whether the problem is caused by the modification about “:root height:”.
I'm also thinking about the method you suggested. But the epub producer should tell me which html should set full-screen background image. That means we should make a rule to communicate this information. I don't think it's quite reasonable. I assuming that the epub producer prefer to use a css style class on body to set the background image. such as:

/* default full-screen background image /
body.background-img-cover {
background: url(../Images/cover.jpg);
background-repeat: no-repeat;
/ background-size: cover; */
background-size: 100vw 100vh;
}

/* default main body background */
body.background-img-repeat {
background:url(../Images/beijing-phone-1.jpg);
background-repeat: repeat-x;
background-size: 100vw 100vh;
}

Or we could handle the body background image at app-level?

I just try the easier way to start.

@JayPanoz
I connect my iPhone to my mac and use Safari Web Inspector to do such attempt. It's really convenience. You could try it to emersion this problem easily.

[ClassWizard]

@JayPanoz
"We indeed have to take the vh unit into account and adding such padding could have messed up some publications in significant ways."
sorry, I just not noticed this. Is that say It was using vh top to set padding that caused my background-image-offset problem?

[JayPanoz]

The :root selector, top: 10vh, height: 80vh, and its original value is 100vh. I use 10vh to be the top and bottom margin. It seems to be fine, but still has another problem that the background image of the first page has shifted some pixels down.

So yeah, this is something we’ve avoided as any element with an height declared with vh will be sized depending on the viewport, and not the 80vh of the :root. We can safeguard images for instance, but it’s a lot more difficult for div containers and stuff like this.

In other words, what you have is this (outer is web view, inner is the :root):

---------------------------------------
|                Top                  |
|-------------------------------------|
|#####################################|
|#####################################|
|#####################################|
|#####################################|
|#####################################|
|#####################################|
|-------------------------------------|
|               Bottom                |
---------------------------------------

To sum things up, the :root doesn’t have padding-top there, but is positioned 10vh from the top, and 0 from the left. So if you don’t want to shift down, you need something like

:root {
  box-sizing: border-box;
  height: 100vh;
  padding-top: 10vh;
  padding-bottom: 10vh;
}

But if an element happens to be height: 100vh in both cases, it will behave like this:

---------------------------------------
|                Top                  |
|-----------------____________________|
|#################|ooooooooooooooooooo|
|#################|ooooooooooooooooooo|
|#################|ooooooooooooooooooo|
|#################|ooooooooooooooooooo|
|#################|ooooooooooooooooooo|
|#################|ooooooooooooooooooo|
|-----------------|ooooooooooooooooooo|
|               Bo|ooooooooooooooooooo|
------------------|ooooooooooooooooooo|
                  |ooooooooooooooooooo|
                  |___________________|

Applying the author’s background-image (or color) is an issue we’ve tried to solve but created other issues we deemed higher priority. Issues include:

• playing nice with height in vh, which is recommended by some ebook vendors e.g. iBooks for images and we wanted to keep some level of interoperability there;
• reading modes overriding those backgrounds, we have an issue for that – note that it doesn’t prevent authors from over-specyfing their selector and override the reading mode;
• we even took a quick look at bleeds (image covering the entire page/screen) but that would require some extra markup because parsing the CSS to find those bleeds is not realistic (huge performance issue).

Mind you, that is something we may revisit at some point but yeah, it’s one of those complex issues with a lot of side effects and we decided to prioritize those side effects since they impacted the samples publishers provided to us.

[ClassWizard]

I tried the css you provided.

:root {
box-sizing: border-box;
height: 100vh;
padding-top: 10vh;
padding-bottom: 10vh;
}

And the result is the same. In both cases (padding-top/top), there is another background image with some offset-Y cover the original background image. I thought it just the original background image shift down at begin, but then I found the extra background image's position is related to the first element in html. Like this:

---------------------------------------
|#####################################|    top part of the background image
|-------------------------------------|
|                                     |
|#############Chapter 1###############|    top part of the extra background image,
|                                     |    mixed with the first element
|                                     |
|                                     |
|                                     |
|                                     |
|                                     |
|-------------------------------------|
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|    bottom part of the background image
---------------------------------------
               page 1


---------------------------------------
|#####################################|    top part of the background image
|-------------------------------------|
|                                     |
|                                     |
|                                     |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|    bottom part of the extra background image,
|                                     |    and it is larger than 100vh
|                                     |
|                                     |
|                                     |
|-------------------------------------|
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|    bottom part of the background image
---------------------------------------
               page 2



---------------------------------------
|#####################################|    top part of the background image
|-------------------------------------|
|                                     |
|                                     |
|                                     |
|                                     |
|                                     |
|                                     |
|                                     |
|                                     |
|-------------------------------------|
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|    bottom part of the background image
---------------------------------------
               page 3 ... last page        they are normal

When I change the first element, the position of the extra background image changes. For example, I reduce the font size of the first element, the image goes up.

I think it is the unit of vh that control the WKWebview's pagination. And I assume that I can control the input ebook not use something like 100vh (at the moment). So I just don't know why it displays as this. Is there some matter with this which I apply to body?

/* default main body background */
body.background-img-repeat {
background:url(../Images/beijing-phone-1.jpg);
background-repeat: repeat-x;
background-size: 100vw 100vh;
}

And is this can be solved？

[ClassWizard]

On the other hand, I have been considering the app-level solution which you suggested.(But I still prefer the css solution at temporary, If possible.😁) Since the full-screen reading bring better user experience，I think the background image should scroll along with the content. (Maybe the top/bottom view should be, too.) That is say, the background image could not be a single image. It may be many same image added to the scroll view or two/three image reuse for transform. This seems to be the navigator's job, perhaps？The most important is where should I put the flag to let app know the background image. Do you have any standard/suggestion about this？

[JayPanoz]

So yeah this can somewhat be solved.

Basically, if the heading (h1) or, more generally, the first-child of the body element, has a margin-top, it will be used.

Pink is the background-color for html, yellow is the one for body. Although body has a margin: 0 (the User Agent default is 8px so you have to reset it anyway), you can see h1’s margin is used to size and position the body.

This is an issue we encountered at the very beginning of ReadiumCSS, because we had empty pages for short XHTML files like the title page, dedication, etc.

That may explain the offset but, strictly speaking, is more of an authoring issue because you have to do the following in CSS to solve it:

h1 {
  margin-top: 0;
  padding-top: {value you want};
}

On a related note, as you can see in this second screenshot, the height of the body can’t be constrained, it will stop where contents stop. There is no way to apply padding to individual column boxes.

So tu put it simply, if you can avoid duplicating the background-image for body, it will make it a lot easier to manage. That’s obviously if the background-images are the same. If they aren’t I’m afraid that you’re out of luck.

[ClassWizard]

Maybe it works on web, but it doesn't work on iOS app...

There is what I get.

Start with this:

:root {
  box-sizing: border-box;
  height: 100vh;
  padding-top: 10vh;
  padding-bottom: 10vh;
}

body.background-img-repeat1 {
	background: url(../Images/beijing-phone-2.jpg);
	background-repeat: repeat-x;
	background-size: 100vw 100vh;
}

The first page: top part of background image still shift down. It seems that the begin point shift down.

Besides, notice that the image is maxed with the heading

It is really strange that the extra background image is larger than 100vh. I don't know why! Should the right image be more higher?

The next page and to the last page are normal. Maybe the repeat-x works (on WKWebview).

On a related note, as you can see in this second screenshot, the height of the body can’t be constrained, it will stop where contents stop. There is no way to apply padding to individual column boxes.

If I set margin-top:-10vh; padding-top:3em;, the top part of the extra background image is gone. But I still have the bottom part of the extra background image.

P.S. The left-top view of "人名索引" is a part of app's view which just like the demo's top bar.

[JayPanoz]

Yeah, this won’t work on the web either and is the reason why I advised to avoid duplicating the background-image for body and only set it for :root (a.k.a. html).

html and body are two different contexts in this background-image case. But the padding on html impacts body sizing so if you have these padding-top: 10vh and padding-bottom: 10vh, body is de facto height: 80vh.

If you set margin-top:-10vh, it leaves you with another 10vh difference. And this is why the bottom of the background-image for body overflows in the next column. On a related note, you might encounter rounding errors web engines can’t prevent anyway, and it impacts sizing/margin/padding sometimes, 100vh can become one screen height and one or two extra pixels. This is not uncommon in current reading apps for instance, and is why some people have been using 99vh for portrait images in body for instance, to cover for the rounding error in case it happens.

By extension, that also explains our logic behind setting sepia and night modes for :root and applying a transparent background-color for other elements – in night mode, everything but anchors (<a>) so it includes body, in sepia mode, we must get around a Chrome bug right now so we’re re-using the background-color but once their bug is fixed, we’ll switch back to transparent.

It’s also worth mentioning we’ve been trying to keep some sort of interoperability with other reading apps in this case. So background-image|color on body is basically working as in any other app we used as a reference (iBooks, Kobo, Kindle, etc.). This should also explain why we didn’t claim ownership of this style for body.

Sorry, there is something I’m failing to understand about that. If the background-images are exactly the same, why not using one for :root and making the background of body transparent?

[ClassWizard]

If the background-images are exactly the same, why not using one for :root and making the background of body transparent?

That is what I exactly want! It works. Thank you very much!

The final solution is:

1. Make the Navigator's view full-screen.
2. Add top and bottom padding by modifing ReadiumCSS-after.css file.

    height: 100vh;
    padding-top: 10vh;
    padding-bottom: 10vh;
/*    padding: 0 !important;*/
    margin: 0 !important;
    box-sizing: border-box;

3. Set background-image for html(:root) in e-book's css file. Then use the css in html file.

html.background-img-repeat {
	background:url(../Images/beijing-phone-1.jpg);
	background-repeat: repeat-x;
	background-size: 100vw 100vh;
}

P.S. There is something should be noticed. When setting background-image, the reading system's background-color mode may not work well. But in my case, I will not allow user to change the background-color mode if the ePub has already set the background-image.

I will close the issue. Thanks again! @JayPanoz

[ClassWizard]

Also，because of the 80vh of content, the media guard (--RS__maxMediaHeight) needs to be adjusted.