Closed kgryte closed 2 years ago
Hmm, that shouldn't be the case, see https://github.com/stdlib-js/www/blob/c3d227a0eb8a0f2db66a429c61cb40e9d324a7e6/src/components/readme/print_button.jsx#L85
For me, printing via the button does indeed switch to light mode and then back?
This should also already work when directly invoking the print dialog window (e.g., via Ctrl + P
on Chrome).
I did this on mobile (iOS Safari), so maybe it only happens there?
Cannot reproduce myself: Has worked on all my browsers on laptop, Android phone, and on an iPad on Safari / Chrome.
Judging from above screenshot, formatting is also off with no left margin.
Not able to reproduce on MacOS Safari.
Is this an older iPhone? Per MDN, beforeprint
has been supported in Safari since v13
(see: https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeprint_event).
It is an older iPhone. Not sure what Safari version it's running though.
Ah...seems as though the Safari version should match the iOS version. I am on iOS 12.5.5, so don't have beforeprint
support, it seems.
Given that users are unlikely to want to print on mobile devices, especially older iOS devices, I'll close this out.
Yeah, Apple doesn't provide updates for their browsers on older devices. Starting with version 13, things work:
Thanks for checking!
I also noticed various other rendering issues when viewing the stdlib docs on my phone, and I'm wondering if some of them are just due to it being an older Safari version.
Currently, if a user tries to print package documentation, the rendered docs use the current theme. Hence, if in dark mode, the print document will also be in dark mode. This is likely not desired (e.g., imagine printing 10 pages with black backgrounds).
Presumably, the fix here is to always switch the application to "light" mode, generate the print docs, and then revert to theme back to its original value before printing.