-
-
Notifications
You must be signed in to change notification settings - Fork 16.7k
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
Conversation
138e2f3
to
eae6704
Compare
eae6704
to
499dc68
Compare
Soooo, I have checked the CSS bug for PDF printing and it appears to be in the 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. |
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. |
I have added a commit to hide the status element off-screen. |
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' ); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Comments taken into account. 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? |
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 :) |
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. |
I can definitely try to merge them if that helps, just tell me. |
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. |
OK, good luck :) |
Merged with two changes;
|
Noice. Will attack the third part of my evil plan next week. |
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 presentpdf.css
: only applied when the query parameter is presentQuestion
Shouldn't the pdf style sheet also be applied only when printing? I believe so but I'm not certain.
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 :-)