Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Absolutely positioned element stays on the previous page #591

Closed
janek37 opened this issue Mar 15, 2018 · 7 comments
Closed

Absolutely positioned element stays on the previous page #591

janek37 opened this issue Mar 15, 2018 · 7 comments
Labels
bug Existing features not working as expected
Milestone

Comments

@janek37
Copy link

janek37 commented Mar 15, 2018

Consider this example:

<!DOCTYPE html>
<html>
  <head>
    <style>
      @page {
        size: A4;
        margin: 1.5cm;
      }

      div {
        border: 1mm solid;
      }

      .filler {
        width: 100%;
        height: 20cm;
        border-color: yellow;
      }

      .main {
        position: relative;
        width: 100%;
        border-color: blue;
      }

      .absolute {
        position: absolute;
        top: 0;
        left: 0;
        border-color: red;
        width: 1cm;
        height: 1cm;
      }

      .long {
        margin-left: 1.5cm;
        width: 15cm;
        height: 10cm;
        border-color: green;
      }
    </style>
  </head>
  <body>
    <div class="filler"></div>
    <div class="main">
      <div class="absolute"></div>
      <div class="long"></div>
    </div>
  </body>
</html>

This is what it looks like converted with WeasyPrint 0.42.2:
test pdf

For reference, this is what comes out of Prince (free version):
prince pdf

As you can see, in WeasyPrint the absolute element as well as the top border stay on the previous page when they should be on the next page with the rest of div.main. Note: the top border is positioned properly when the absolute element is removed.

@liZe liZe added the bug Existing features not working as expected label Mar 18, 2018
@Tontyna
Copy link
Contributor

Tontyna commented Mar 22, 2018

Print Preview in my Browser (Pale Moon) paginates the sample like this:
palemoon
WeasyPrint pagination is buggy, but it's debatable whether Prince does it right ;)

@liZe
Copy link
Member

liZe commented Mar 23, 2018

WeasyPrint pagination is buggy, but it's debatable whether Prince does it right ;)

Exactly. Having the blue box on a separate page (as Prince does) is an implementation detail that is not in the CSS specification AFAIK.

The "real" problem in WeasyPrint is the missing blue and green borders on the first page. You can find another example on the W3C testing suite, where the purple border should be visible from the top to the bottom of the pages.

This problem is not directly related to the position: absolute / relative property, it also happens in normal flow. It's a very old bug that should be surprisingly easy to fix: at the end of the page, we have to increase the size of split boxes to make them reach the bottom of the page.

@liZe liZe added good first issue Issues that can be quite easily solved by Python developers with a good CSS background conformance labels Mar 23, 2018
@janek37
Copy link
Author

janek37 commented Mar 28, 2018

It's a very old bug that should be surprisingly easy to fix: at the end of the page, we have to increase the size of split boxes to make them reach the bottom of the page.

Do you mean that in my example everything would be fine if only the border on the first page extended to the bottom? I don't think so, in my opinion the red frame should be next to the green one and not on separate pages. In other words, the green frame should take 100% of the parent's height, as in Prince and Pale Moon.

@liZe
Copy link
Member

liZe commented Mar 28, 2018

Do you mean that in my example everything would be fine if only the border on the first page extended to the bottom?

I don't know if would be fine, but AFAIK it would be right according to the spec.

I don't think so, in my opinion the red frame should be next to the green one and not on separate pages.

In my opinion we should read CSS Fragmentation to not rely on our opinions anymore 😉.

@janek37
Copy link
Author

janek37 commented Apr 12, 2018

I admit that I don't have resources to read and understand the standard. But I want to be able to make boxes next to each other and I can't see how it's a good idea to make one of them jump to the next page while the first one stays. If it can't be fixed, I have to move from WeasyPrint and find something that can do this.

@liZe liZe removed the conformance label Apr 1, 2019
@liZe
Copy link
Member

liZe commented Sep 16, 2019

The "real" problem in WeasyPrint is the missing blue and green borders on the first page. You can find another example on the W3C testing suite, where the purple border should be visible from the top to the bottom of the pages.

This problem is fixed.

In my opinion we should read CSS Fragmentation to not rely on our opinions anymore.

The spec says that we can break:

Between the content edge of a block container box and the outer edges of its child content (margin edges of block-level children or line box edges for inline-level children) if there is a (non-zero) gap between them.

As there's no gap between the blue and the green boxes, we can't break here.

@grewn0uille grewn0uille removed the good first issue Issues that can be quite easily solved by Python developers with a good CSS background label Sep 16, 2019
@liZe
Copy link
Member

liZe commented Apr 5, 2022

Here’s what we get with the latest stable version of WeasyPrint: absolute.pdf

This bug has probably been fixed in 54.x with #36 🎉.

@liZe liZe closed this as completed Apr 5, 2022
@liZe liZe added this to the 54.0 milestone Apr 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing features not working as expected
Projects
None yet
Development

No branches or pull requests

4 participants