I've recently been working on a print stylesheet for a website, and I realized that I was at a loss for effective ways to tweak it. It's one thing to have a reload cycle for working on the on-screen layout:
change code
command-tab
reload
but that whole process gets much more arduous when you're trying to print:
change code
command-tab
reload
print
squint at print-preview image
open PDF in Preview for further inspection
Are there tools I'm missing out on here? Does WebKit's inspector have a "pretend this is paged media" checkbox? Is there some magic that Firebug (shudder) can do?
There is an option for that in Chrome's inspector.
Open the DevTools inspector (mac: Cmd + Shift + C , windows: Ctrl + Shift + C)
Click on the Toggle device mode icon , located on the upper left corner of the DevTools panel. (windows: Ctrl+Shift+M, mac: Cmd+Shift+M).
Click on the More overrides icon in the top right corner of the browser viewport to open the devtools drawer.
Then, select Media in the emulation drawer, and check the CSS media checkbox.
This should do the trick.
Update: The menus have changed in DevTools.
It can now be found by clicking on the "three-dots" menu in the top right corner > More Tools > Rendering Settings > Emulate media > print.
Source: Google DevTools page*
I'm assuming you want as much control of the printed window as possible without using a HTML to PDF approach... Use #media screen to debug - #media print for final css
Modern browsers can give you a quick visual for what's going to happen at print time using inches and pts in a #media query.
#media screen and (max-width:8.5in) { /* resize your window until the event is triggered */
html { width:8.5in; }
body { font: 9pt/1.5 Arial, sans-serif; } /* Roughly 12px font */
...
}
Once your browser is displaying "inches" you'll have a better idea of what to expect. This approach should all but end the print preview method. All printers will work with pt and in units, and using the #media technique will allow you to quickly see what's going to happen and adjust accordingly. Firebug (or equivalent) will absolutely expedite that process. When you've added your changes to #media, you've got all the code you need for a linked CSS file using media = "print" attribute - just copy/paste the #media screen rules to the referenced file.
Good luck. The web wasn't built for print. Creating a solution that delivers all of your content, styles equal to what's seen in the browser can be impossible at times. For instance, a fluid layout for a predominantly 1280 x 1024 audience doesn't always translate easily to a nice and neat 8.5 x 11 laser print.
W3C reference for purusal: http://www.w3.org/TR/css3-mediaqueries/
Chrome 48 you can debug print styles within the Rendering tab.
Click the menu icon top right of inspector and Rendering Settings.
Edit
For Chrome 58 the location has changed to Web Inspector > Menu > More Tools > Rendering
In Chrome v41, it's there, but in a slightly different spot.
There's an easy way to debug your print stylesheet without switching any media attribute in your HTML code (of course, as pointed out, it doesn't solve the width / pages issue):
Use Firefox + Web Developer extension.
In the Web Developer menu, choose CSS / Display CSS by Media Type / Print
Go back to Web Developer menu, choose Options / Persist Features
Now you are viewing the print CSS and you can reload your page indefinitely.
Once you're done, uncheck "Persist Features" and reload, you'll get the screen CSS again.
HTH.
Chrome's UI is different again as of v53.
I don't need to use this feature often, but whenever I do, it takes me forever to figure out where the Chrome team has moved it since the last time I burned cycles trying to track it down.
Notice it's the ... menu in Dev Tools pane not the ... menu in Chrome Browser pane.
Now scroll down in the Rendering section. It's often below the fold.
Following up to the answer by rflnogueira, the current Chrome settings (40.0.*) will look like below:
Just show the print stylesheet in your browser using media="screen" while debugging. The print preview view uses the same rendering engine as normal browsing mode so you can get accurate results using that.
2019 - Updated instructions
Open Chrome inspector
From Mac => option + command + i
From Windows => F12
Click on the little 3 dots, customize and control devTools
Select More Tools
Select Rendering
Scroll to the bottom to Emulate CSS Media
Select print from the down arrow
If you have a print function that rewrites the content of the page to a new window with your print style sheet referenced you'll get a much better idea of what its going to look like on paper , and you'll be able to debug it with the likes of firebug too.
Heres an example of how this can be done with JavaScript / jquery
$("#Print").click(function () {
var a = window.open('', '', 'scrollbars=yes,width=1024,height=768');
a.document.open("text/html");
a.document.write("<html><head>");
a.document.write('<link rel="stylesheet" href="css/style.css" />');
a.document.write('<link rel="stylesheet" href="css/print.css" />');
a.document.write("</head><body>");
a.document.write($('#Content').html());
a.document.write('</body></html>');
a.document.close();
a.print();
});
In Firefox (87.0), the "DOM and Style Inspector" has a toggle button for print media simulation.
One drawback is that it does not clearly delineate the page boundaries.
In DreamWeaver there is a toolbar that shows virtually any rendering option you want:
screen, print, handheld media, projection screen, tv media, desitn time style sheets, etc.
This is what I use especially because it: instantly shows a preview with 1 single press of a button.
I use macros to send keypress and mouse clicks repeatedly.
Under Windows, AutoHotKey is a great software and under OS X you can read about Automator sort of an alternative AHK for OsX.
Under Windows (replace Ctrl by Cmd under OS X) "Ctrl-s / switch to Fx window wherever it is in the list of windows opened / Ctrl-r" bound to 1 unused key avoids frustration from uninteresting tasks and will ultimately save my arms from RSI :)
Related
I've been creating a website and a portion of the site is designed to be printed on tabloid paper in portrait mode. The problem I'm having is when the print dialog comes up in Chrome it's missing the "Layout" options.
In this screen shot, the left side shows how my dialog box looks vs. how it looks when I print other websites. The ironic thing is even other sites I've created have the option as shown on the right, which is the desired behavior.
My question is, what controls this behavior? How do I correct it? In searching the web the only mention I've see of this is when Chrome is displaying PDF files, but I'm displaying a web page.
Any insight you can give would be greatly appreciated.
Thanks in advance
If you have an #page size declaration in the print CSS, this will override (and hide) the orientation on the print dialog. To override a declaration that is set elsewhere (e.g. Bootstrap 4 does this) you can add:
#page {
size: auto;
}
Just a quick addition to the accepted answer..
For those who are unable to edit the css of the page you're trying to print, you can install the Chrome extension called 'Stylus' (link here), and create a new style with just the above suggestion:
#page {
size: auto;
}
This will enable the missing options from the print dialog on any/every web page..
I'm working on some print stylesheets. The only way I can view the results of my changes is by using a print preview. It's very tedious and clunky. Even though it will be inevitable once I need to test page-breaks, I have been trying to figure out if there is a way to spoof the #media print in the browser so I can use the inspector, and see all of the things that are switched around to look different for printers.
A good example is that if you have Bootstrap installed, they are using a trick with anchors so that the URL is printed out in parens after the anchor text. So, while I can temporarily change my own print stylesheet to #media screen, I don't see those Bootstrap #media print things until I hit print preview.
Yes.
In chrome go to Developer Tools > Emulation > Media > check css media and select print from the dropdown
I have simple xpage with dynamic views. I can switch between them via Navigator that I added from Extension Library. Everything works OK, but the problem is with the CSS. To the navigator I have 1 style sheet attached, which contains the following:
.lotusSelected{background-color:none;}
And this is where it gets interesting- whenever I open the xpage in Chrome web browser, try to open any of the navigator elements and look at the code via Chrome devkit (or whatever it is when you press F12) it shows that the code above now is:
.lotusSelected{background-color:red;}
...So it pretty much changes my CSS. I don't understand why this is happening. Also, it does not happen in Internet Explorer. Can anyone explain me why this occurs and how do I fix it?
Maybe your css style is being overwritten by another one (i.e. from OneUI)
Check if it appears with strikethrough style below in your css debugger.
In that case, you can add !important in your style:
.lotusSelected{background-color:none !important;}
(FYI: this is a css anti-pattern :P )
If you want the background-color to be nothing then use transparent instead of none.
I've set up a print stylesheet and in firefox it looks well.
In Chrome the whole page is broken in the print preview (CTRL+P), but if I open the Chrome DEVTools (F12) and use the emulate CSS media function the page looks correct - like in firefox.
The weird thing is, if I open the print preview again, after I've activated the emulate option once, the page looks correct in the print preview! Even If I just activate and then deactivate the emulate option, the print preview is always correct after doing that!
My print.css starts with
#media print { ... }
and is included in the page <head> like this:
<link rel="stylesheet" type="text/css" href="print.css" media="print">
I've tried to remove the media="print" but nothing changes.
In your print style sheet, you need do add the following:
* {
transition: none !important;
}
It appears that Chrome doesn't disable the transition property for print media.
Here is where I found the answer.
If you have not find solution in given answers then i have something to say about it:
in Chrome DEVTools print option in emulation css media is only for applying print css rules to the page, for testing purpose, it does not account for all the other things that go along with print, it display the print preview but sometimes it do not display the print page as actual print preview.
if you are using bootstrap then if you are using only col-md-* or col-sm-* it will not work, but if you use col-xs-* then it will work because The issue is that the page itself is small in terms of pixels, so bootstrap thinks it needs to apply the xs style.
And different browser behaves differently in printing the page.The only optimal way to test print is by actually printing, or printing to pdf.
I ran into the exact same head breaking problem and I've been able to fix it.
In my case the problem was caused by using a custom #font-face for the 'print' CSS which i did not use in the 'screen' CSS.
It seemed the browser dit not load the custom #font-face from the print stylesheet for the first preview and renders the page more or less empty. It would render perfectly on the second print preview.
My solution was to load the same #font-face rule from the pint css also in the screen css. That way the font is loaded already by the browser when viewing the print preview and it all works like a charm.
To add to Ustice's answer and Jeeva Jsb's comment: you may need to allow the DOM to rerender after applying the transition: none !important rule. I accomplished this by adding a print CSS class to the body before I programmatically printed the page:
CSS:
body.print * {
transition: none !important;
}
JS (using jQuery):
$('body').addClass('print');
setTimeout(function() {
window.print();
}, 0);
Don't forget to remove the print class once your user has finished printing the page. (See how to detect window.print() finish.)
I've been editing CSS using Firebug in Firefox, but recently noticed that Chrome is rendering my pages much quicker (with scrolling, interactive elements etc) and wanted to switch to it.
I found Chrome shows the computed CSS and what attributes are overruled in the stack and I can alter them one-by-one but what I liked about Firebug was that I could just edit the entire stylesheet in a real-time text editor. Is this same feature somewhere in the Chrome developer panel, or is there a Chrome extension that lets me alter the stylesheets this way?
In current versions of Chrome (I'm running 16) you don't need any external add-ons.
Right click anywhere in your page, choose inspect element, then in the window that shows up click the Resources tab, then in the left panel select the stylesheet you want to edit. To begin editing you need to first double click, over the css text.
Try StyleBot. It can also save edited CSS.
You can edit any property or create a new property by double click on an entry or empty space in Elements panel's styles pane. There is no way to edit entire css file just as text at the moment.
I use live.js! As you edit your css file it shows you the results realtime in your browser without having to refresh. http://livejs.com/
I've spend countless hours testing almost every Chome extension i could find (including stylebot) to mimic the live CSS editing of Firebug in Firefox. None to date have that same workflow. Live.js is the closest.
Have you tried the Web Developer Toolbar extension's CSS->Edit CSS tool?
https://chrome.google.com/extensions/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
Web Developer Toolbar for Chrome > CSS > Edit CSS
there's a semi-working firebug extension but it's not exactly perfect yet.
User Firebug Lite. It's also available as an extension to Chrome.
You are looking for this - Live Stylesheets
I wrote the LiveCSSEditor 4 years ago for exactly this reason. FireBug in Firefox would let me free-hand write CSS into the page, but nothing else in Chrome would.
I still use it today and have yet to find a better solution. It may work for you as well. :)