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.

Sign up for GitHub

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

Jump to bottom

target-counter(attr(href), page) renders “0” instead of the actual page number #1491

Closed
devopsix opened this issue Nov 10, 2021 · 1 comment
Closed

target-counter(attr(href), page) renders “0” instead of the actual page number #1491

devopsix opened this issue Nov 10, 2021 · 1 comment
Labels
bug Existing features not working as expected
Milestone
54.0

Comments

@devopsix
Copy link

target-counter(attr(href), page) seems to render “0” instead of the actual page number if the element into whose ::after it is rendered has display: flex; set.

Given this markup and styles:

toc.html

<!DOCTYPE html>
<html>
<head>
    <link href="toc.css" rel="stylesheet" />
</head>
<body>
    <nav id="toc1">
        <ul><li><div><a href="#article-1">...</a></div></li></ul>
    </nav>
    <nav id="toc2">
        <ul><li><div><a href="#article-1">...</a></div></li></ul>
    </nav>
    <nav id="toc3">
        <ul><li><div><a href="#article-1">...</a></div></li></ul>
    </nav>
    <article>
        <h1 id="article-1">Article 1</h1>
    </article>
</body>
</html>

toc.css

article {
    page-break-before: always;
}

li a::before {
    content: target-text(attr(href));
}
li a::after {
    content: target-counter(attr(href), page);
}

#toc2 li a {
    display: flex;
}

#toc3 li div {
    display: flex;
}

When rendering this to PDF with Weasyprint 53.3 (weasyprint toc.html toc.pdf) then the output document should contain 3 times the same link text.

Expected output:

expected-output

But for the second link text, “0” is rendered for the target page counter instead of “2”.

Actual output:

actual-output
@liZe liZe added the bug Existing features not working as expected label Nov 14, 2021
@liZe
Copy link
Member

liZe commented Nov 14, 2021

Hello, and thanks for this bug report. Having a counter value changed by the display property is really strange, we have to see what’s going on.

@grewn0uille grewn0uille added this to the 54.0 milestone Nov 18, 2021
@baloersch baloersch mentioned this issue Dec 31, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Existing features not working as expected
Projects
None yet
Milestone
54.0
Development

No branches or pull requests
3 participants
@liZe @grewn0uille @devopsix