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

string-set does not work with display: none #473

Open
jmidgren opened this issue May 31, 2017 · 8 comments
Open

string-set does not work with display: none #473

jmidgren opened this issue May 31, 2017 · 8 comments
Labels
bug Existing features not working as expected

Comments

@jmidgren
Copy link

When using -weasy-string-set with content that is hidden using css "display: none;" the content is not copied to the css string.

Example:

...
<div id="myvalue">This is the text</div>
...
@page {
  @top-center {
    content: string(myvalue);
  }
}

#myvalue {
  display: none;
  -weasy-string-set: myvalue content();
}

Here I expect the div not to show but "This is the text" to appear in the page header. Instead the text is hidden both in the body div and the header.

If I remove the "display: hidden;" directive from my style sheet, the text appears both in the document body and header.

I'm not 100% sure this is an error (the feature is after all only from a draft specification), but it seems reasonable that it should be possible to copy hidden text into CSS strings.
@jmidgren
Copy link
Author

A workaround is to avoid "display: none" and instead use e.g. "font-size: 0pt;" but that may have other implications on how style is applied to your document.

@liZe
Copy link
Member

liZe commented May 31, 2017

I'm not 100% sure this is an error (the feature is after all only from a draft specification)

It's only a draft, but it's explicit:

The content values of named strings are assigned at the point when the content box of the element is first created (or would have been created if the element’s display value is none).

It's a bug!

@liZe liZe added bug Existing features not working as expected conformance labels May 31, 2017
@liZe liZe mentioned this issue Feb 15, 2018
Closed
@liZe liZe changed the title -weasy-string-set does not work with display: none string-set does not work with display: none Feb 15, 2018
@Tontyna
Copy link
Contributor

Tontyna commented Feb 15, 2018 •
edited

Workaround for named strings from META elements:

head, 
head > title, 
head > meta {display:inline}

meta[author] { string-set: author attr(author); }
head > title { string-set: title content(); }

⚠️ Be aware that this workaround generates contents. With styles applied. Even if you put it out of sight with e.g. visibility: hidden; position: absolute; left: -1000.

Had a hard time to figure out why my front page refused to adopt the @page frontmatter rule until I eventually realized that the (invisible but present) metas trigger the plain @page :first unless told otherwise.

@eligiobz
Copy link

eligiobz commented Feb 15, 2018 via email

@Tontyna
Copy link
Contributor

Tontyna commented Feb 15, 2018

Don't know Jinja2, but I'm shure there's a place to tell the template engine which css styles to apply. Something like <style>...</style> or <link rel="stylesheet" ...> in html. Or maybe there's an include-statement for stylesheets? The same location where -- I suppose -- you already tell WeasyPrint what e.g. @page style to use.

@larrykollar
Copy link

If I have a standard <meta> tag like this:

<meta name="author" content="Joe Bloggs"/>

Then I would expect (according to Tontyna's workaround) this would work:

head > meta { display: inline; }
meta[name="author"] { string-set: author attr(content); }

It's not working in Weasyprint, but does work in another formatter I've tried (Oxygen PDF Chemistry). Am I missing something?

Maybe the fix is to change the UA stylesheet; since <meta> carries its content in attributes and is otherwise empty.

@Smylers
Copy link
Contributor

Smylers commented Jan 24, 2019

Then I would expect (according to Tontyna's workaround) this would work:

head > meta { display: inline; }
meta[name="author"] { string-set: author attr(content); }

You've missed a line out of Tontyna's workaround: you're saying that <meta> should be displayed, but I'm guessing it still won't be because it's inside <head>, which is still left as not being displayed.

@larrykollar
Copy link

You are correct, @Smylers. Changing the selector to head, meta did the trick; now I have two blank pages at the beginning of the PDF because I have h1 do page-break-before: right. Once I get front matter set up, that won't be an issue.

Lots of moving parts to coordinate, but once you get it all together it seems to work pretty well!

@grewn0uille grewn0uille removed the bug Existing features not working as expected label Sep 16, 2019
@liZe liZe added bug Existing features not working as expected and removed conformance labels Dec 17, 2019
@3j14 3j14 mentioned this issue Mar 19, 2020
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
No milestone
Development

No branches or pull requests
7 participants
@Smylers @liZe @grewn0uille @jmidgren @eligiobz @larrykollar @Tontyna