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

Bundler friendliness (part II) - Repackage print style sheets #2633

Merged
merged 3 commits into from
Mar 13, 2020

Conversation

quilicicf
Copy link
Contributor

What this PR does

It applies paper.css and pdf.css conditionally (depending on whether the query parameter ?print-pdf is defined) so they can both be loaded in the presentation without adding a script.

The style sheets can now be both imported and only apply on the following conditions:

  • paper.css: only applied when printing (media query) and the query parameter is NOT present
  • pdf.css: only applied when the query parameter is present

Question

Shouldn't the pdf style sheet also be applied only when printing? I believe so but I'm not certain.

⚠️ The current version is a bit buggy

I didn't validate using the test suite because it is commented out (see gulpfile).

I did inspect the result on the page demo.html though and found a nasty bug that I don't have the time to locate right now.

The first slide when printing to pdf with black theme follows the theme correctly but all the other slides have a white background.

I'll try to fix this ASAP, don't merge in the meantime :-)

@quilicicf quilicicf mentioned this pull request Mar 10, 2020
@quilicicf quilicicf force-pushed the dev_repackagePrintStyleSheets branch from 138e2f3 to eae6704 Compare March 11, 2020 12:09
@quilicicf quilicicf force-pushed the dev_repackagePrintStyleSheets branch from eae6704 to 499dc68 Compare March 11, 2020 12:10
@quilicicf
Copy link
Contributor Author

Soooo, I have checked the CSS bug for PDF printing and it appears to be in the dev branch too.
For an unknown reason, the option background graphics in Chrome print preview was auto-activated when testing on your branch but not on mine 🤔

Turns out the backgrounds are OK on both branches when turning it on.

There's one remaining issue (on both branches too), a page is added when printing to PDF, and given it has no content, it also has no background => it is white even with dark themes.

@quilicicf
Copy link
Contributor Author

Dug a bit further. The additional page in the PDF is actually added because there's a tiny DOM element that gets added at the end of the presentation that looks like this:

<div class="aria-status" aria-live="polite" aria-atomic="true" style="position: absolute; height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px);">
    Presentation's first slide's text here
</div>

Switching the height to 0 removes the additional page.

@quilicicf
Copy link
Contributor Author

I have added a commit to hide the status element off-screen.
It works for me now.
Can you check that I didn't wreck anything @hakimel ?

js/reveal.js Outdated
@@ -368,7 +370,7 @@ export default function( revealElement, options ) {
// Limit the size of certain elements to the dimensions of the slide
createStyleSheet( '.reveal section>img, .reveal section>video, .reveal section>iframe{max-width: '+ slideWidth +'px; max-height:'+ slideHeight +'px}' );

document.body.classList.add( 'print-pdf' );
document.querySelector('html').classList.add( 'print-pdf' );
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use document.documentElement instead of querySelector('html'), to match how the rest of reveal.js accesses it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

js/reveal.js Outdated
@@ -292,6 +292,8 @@ export default function( revealElement, options ) {
statusElement.style.position = 'absolute';
statusElement.style.height = '1px';
statusElement.style.width = '1px';
statusElement.style.top = '-1px';
statusElement.style.left = '-1px';
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The status element is used for accessibility—it calls out text to a screen reader. It serves no purpose in PDF exports though, so maybe we can add .aria-status { display: none; } to the pdf print sheet instead of changing it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, seems reasonable. I'll do that.

@quilicicf
Copy link
Contributor Author

Comments taken into account.
Another thing I saw is that the comments stay in the CSS after SASS compilation. And they jump to the top of the file, meaning they have no context.

Shouldn't they disappear in the CSS? I can configure the gulp task but I want to be sure what's expected here.

Example, pdf.css starts like this:

/* Copyright... */

html.print-pdf {
  /* Remove any elements not needed in print. */
  /* Slide backgrounds are placed inside of their slide when exporting to PDF */
  /* Display slide speaker notes when 'showNotes' is enabled */
  /* Layout option which makes notes appear on a separate page */
  /* Display slide numbers when 'slideNumber' is enabled */
  /* This accessibility tool is not useful in PDF and breaks it visually */ }

I don't think Reveal should add the comments in "production" files, should it?

@hakimel
Copy link
Owner

hakimel commented Mar 12, 2020

PR is looking good so I'm gonna start testing.

I'll take a look at the build to see why it's not removing those comments. The whole dev branch—including the new gulp build—is undergoing some pretty big changes so it's not in a stable place yet :)

@hakimel
Copy link
Owner

hakimel commented Mar 12, 2020

Also one thought that springs to mind looking at this is why don't we just bundle the pdf and paper styles inside of reveal.css to avoid the separate imports? I'll poke around and see if that's feasible while testing.

@quilicicf
Copy link
Contributor Author

I can definitely try to merge them if that helps, just tell me.
I was also wondering if the pdf thing should not be also in the print media query ?
I'm not sure it serves a purpose to wreck the style of the presentation when the ?print-pdf parameter is there and the user is not trying to print.

@hakimel
Copy link
Owner

hakimel commented Mar 13, 2020

Let's avoid wrapping the PDF styles in a media query. There are multiple scripts out there for exporting reveal.js presentations to PDF, including our implementation at Slides.com, that may be affected by that.

I'm experimenting with building the print styles into the main stylesheet—will let you know how it goes.

@quilicicf
Copy link
Contributor Author

OK, good luck :)

@hakimel hakimel merged commit 92e3a36 into hakimel:dev Mar 13, 2020
@hakimel
Copy link
Owner

hakimel commented Mar 13, 2020

Merged with two changes;

  1. Paper and PDF print styles are now baked into reveal.css 🥳 Updated README accordingly.
  2. The print to paper styles were severely outdated so I updated them.

@quilicicf
Copy link
Contributor Author

Noice. Will attack the third part of my evil plan next week.
I need to make the speaker notes plugin bundler-friendly which won't be a piece of cake.
I'll share my ideas first as this is gonna be more complex by far than the two first parts IMO.

R0bes pushed a commit to R0bes/Terraform-Presentation that referenced this pull request Jun 7, 2021
srwohl pushed a commit to srwohl/phantom-pres that referenced this pull request Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants