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

Footnote Area: Support Max Height #1674

Closed
andrewerlanger opened this issue Jul 7, 2022 · 2 comments
Closed

Footnote Area: Support Max Height #1674

andrewerlanger opened this issue Jul 7, 2022 · 2 comments
Labels
bug Existing features not working as expected sponsored Issues sponsored to be resolved faster
Milestone

Comments

@andrewerlanger
Copy link

Hi there!

First and foremost: many thanks for the amazing work you've done on the footnotes front already, really impressive stuff 👏

I just wanted to add one more item to the short list of features missing from the specification: supporting the max-height property for the footnote area.

Per the w3.org footnote specs:

The max-height property on the footnote area limits the size of this area, unless the page contains only footnotes (as may happen on the last page of a document).

Since it is undesirable for a page to consist only of footnotes, user agents may set a default max-height value on the footnote area.

As it stands, setting a max-height on the footnote area will technically limit the height, but the footnotes themselves overflow from the container rather than being displayed on the following page.

For example, the following css...

@footnote {
  max-height: 6cm;
  background: red;
  float: bottom;
}

...produces this in the PDF:
image

Ideally, footnotes 5. onwards would be displayed on the following page 🤓

@liZe liZe added the bug Existing features not working as expected label Jul 7, 2022
@grewn0uille grewn0uille added this to the 56.1 milestone Jul 8, 2022
@grewn0uille grewn0uille added the sponsored Issues sponsored to be resolved faster label Jul 8, 2022
@liZe liZe pinned this issue Jul 10, 2022
liZe added a commit that referenced this issue Jul 11, 2022
This solution is by far the cleanest I’ve found to follow max-height without
changing everything. Contrary to my previous tries, it keeps the original style
untouched, doesn’t add dirty properties on the box and only assumes that the
overflowing children are caused by the max-height set on the area. This last
condition is probably true in real-life cases, but we’ll sure find soon that
other users don’t have the real life we expect them to have.

It also has the side effect of following the height attribute too. There’s
nothing in the specification about which properties are allowed in @footnote
rules, only a classical "How would one describe this in the grammar of
CSS3-Page?", so … who cares? We’ll sure find soon that other users actually
care more than the W3C.

The existing tests pass, that’s good news, but we’ll need solid new tests.

Related to #1674.
grewn0uille added a commit that referenced this issue Jul 13, 2022
@liZe liZe closed this as completed in adec43a Jul 13, 2022
@liZe
Copy link
Member

liZe commented Jul 13, 2022

Hi @andrewerlanger

The feature has been added and tested, we hope that it works well for your use case!

@andrewerlanger
Copy link
Author

@liZe thanks for the super quick turnaround, much appreciated! 🙏

@grewn0uille grewn0uille unpinned this issue Jul 24, 2022
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Aug 18, 2022
Version 56.1
------------

Released on 2022-07-24.

Bug fixes:

* `1674 <https://github.com/Kozea/WeasyPrint/issues/1674>`_:
  Follow max-height on footnot area, with financial support from Code & Co.
* `1678 <https://github.com/Kozea/WeasyPrint/issues/1678>`_:
  Fix gradients with opacity set
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 sponsored Issues sponsored to be resolved faster
Projects
None yet
Development

No branches or pull requests

3 participants