When printing an HTML document the bgcolor of a table cell is ignored.
What else is ignored when one tries to print documents?
I'm trying to make a particular website look a certain way when printed out but am having some difficulty doing so not knowing what attributes printers use and which ones they ignore.
Thanks!
The link you're referring to is about browser-specific print handling. Check out the each supported browser's printing properties for more info there.
Regularly, though, WYSIWYG when it comes to printing an HTML page.
You could specify a specific CSS file for printing by adding the following tag to your <head> tag:
<link rel="stylesheet" href="print.css" type="text/css" media="print" />
Where print.css is the path to your CSS file.
Addition:
Though you can't override the Browser-preferences, there's nothing you can do to print your BG in non-allowing browsers. Check the printing preferences for those options.
My best idea is to export your web-page to PDF and print that. See web2pdfconvert, for example of such a service. You could also install a plugin on your server side that does exactly the same thing, and the send it your HTML via AJAX.
Another Addition: Take a look at jsPDF which is completely client side and thus simpler. You can use it to convert the page to pdf and than print it as it is.
Things that may be ignored are completely dependent upon the browser in question and the print settings for that browser.
For example, in Chrome you can turn off headers/footers and backgrounds. In Firefox you have control over backgrounds. In IE you have some refined control over frames, linked documents and optionally printing a table of links.
Your best bet is to simply provide a style sheet for media="print" and define how you want the page to look.
Related
I am working on an HTML page (no server-side scripting) web page with JavaScript.
That has to be modified dynamically by the user. Then I want to let the user save this page locally as a .html file.
To achieve this, I suggest the user to use the browser function "Save
page as...".
I do that because I want the user to have complete local access to this file when off-line.
The question is that I would like the user to save the page in Printer Version after I have hidden all the stuff he does not need (menus, instructions, etc.).
I have already linked the css stylesheet for printing (with "media=print") and I would like to use it to change the aspect of the page before the user save it.
(It's not possible to use an iFrame because the browser function "Save page as..." saves always an entire page.)
I ask if anybody know a way to link dynamically a new
css-stylesheet to the page that will replace the css style hiding
the unwanted css classes.
The solution must work in recent versions of browsers, not old.
You can add a new style sheet with your print rules to your document as such when needed;
$('head').append('<link rel="stylesheet" href="printerFriedly.css" type="text/css" />');
On our site we load stylesheets dynamically based on whether the display is retina or not. Right now, we are using document.write for each <link href="stylesheet.css"> we insert in the page, with different css files if the display is retina.
However, this hurts performance because it causes the css files to load synchronously, as the browser has no way of parsing the javascript to load the next file before the previous one is finished. I believe we can reduce page load time if we take advantage of modern browsers' capability to look ahead and fetch resources asynchronously - in another words, if we load the CSS files in parallel instead.
My current solution is to create a <link id="link-tag-id" href=""> tag for every stylesheet to be loaded, immediately followed by a script which determines the retina status, then fills in the quotations with the appropriate file, along the lines of:
document.getElementById("link-tag-id").setAttribute("href", "retina-stylesheet.css")
This seems to work fine, and when I examine the network waterfalls in Chrome developer tools, as well as on WebPageTest.org (running Chrome, Firefox, and IE), the stylesheets indeed load in parallel. However, it seems a little hacky. I was wondering if there are any dangers to creating a <link> tag with an empty href attribute, and if so, what are they?
On a broader note, are there any other recommendations on how to load CSS dynamically and asynchronously?
Thanks for your help!
EDIT: I just discovered this works too:
document.getElementById("link-tag-id").href = "retina-stylesheet.css"
You could use media queries inside your stylesheet to determine if the display is a retina display, then load in the required CSS.
http://css-tricks.com/snippets/css/retina-display-media-query/
http://mobile.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/
I'm creating a web based flyer designer for dog walkers to customize flyers to print off. It's very basic and uses jQuery to change the contents/text of a DIV to what they want on the flyer...
My problem is how to let them print the flyers. Ideally, they want to choose between 2 or 4 flyers per A4 page. Or to export as pdf or image to take to a printer. I've looked into exporting html/css as a PDF or image but can't seem to find anything that suits the situation.
Any help is appreciated.
Thanks
Webkit HTML to PDF\Image should do exactly what you want:
http://code.google.com/p/wkhtmltopdf/
I would recommend using the print media type in the main stylesheet:
#media print
{
/* style sheet for print goes here */
}
Or, separate the print styles in it's own stylesheet:
<link href="foo.css" media="print" rel="stylesheet" type="text/css" />
This allows you to define custom styles that are displayed when using the browser's Print dialog (File->Print...). That way, your end-user can print to their printer, print-to-PDF (or Microsoft XPS Document Writer), or whatever else they want to print to, without relying on a 3rd party library that, from past experience, is subject to quirks and inaccuracies in converting CSS styles.
You have loads of options... here is just one, in case you want to export your webpage to PDF without much work:
Recommendation? for our specific HTML -> PDF project
Just for more options, there's also phantomJS, which uses webkit rendering engine as well. QtPDF is the pdf engine it uses behind the scenes
http://phantomjs.org/
This assumes you have a server that you can execute command line scripts off of. Ive used this recently in a project, and it works great for converting HTML->PNG. Have not personally tested the PDF functionality extensively.
when printing a page, the javascript code seems to be executed.
how can I determine, if the page is currently being printed? I do some js-resizing, and have to handle printing a little bit different.
You can't, except for IE browsers. No other browser has a before print event. You can, however, target a specific stylesheet to only apply while printing:
<!-- In head -->
<link rel="stylesheet" type="text/css" media="print" href="print.css" />
This stylesheet will be applied before printing. This allows you to perform some amazing changes, including hiding major sections, moving items around, and performing print-only styling, such as page breaks.
Another option is to provide the user with a "Print this Page" button. That button can handle your JavaScript, call window.print(), and revert the changes:
function printMe() {
// perform changes
window.print();
// revert changes
}
The window.print() method always blocks (in every browser I've tested), so it's safe to immediately revert the changes afterward. However, if the user choose to print via the menu or toolbar, you are out of luck.
One way I handled that case in a complex web-app was to have a print stylesheet that hid everything but a special DIV. If the user clicked print, they would get a warning message. If they clicked the print button, then that div would be populated with the correct information. It's not great, but at least they didn't get several pages of garbage.
AFAIK there is no general possibility. IE has onbeforeprint and onafterprint which are now added also to Firefox 5/6+ (I dont know for sure). Consider using print specific stylesheets
<link rel="stylesheet" href="print.css" type="text/css" media="print" />
Other relevant questions
onbeforeprint() and onafterprint() equivalent for non IE browsers (PHP, MySQL, JavaScript, HTML)
Trigger resize event on print
What event is fired when window.print() is called?
A relative of mine who started to learn Web Development asked me this question.
Why <script src="min.js"></script> and <link rel="stylesheet" href="min.css">? Why not <style href="min.css"></style>. Why do we use link tag to add external CSS in the page but when we link CSS to page but we use <style>...</style> when we write CSS inside <head>?
I told him that it's because of spec. Is there any more info to give to him?
It's historical... coincidence? You can recommend him reading part about Past of diveintohtml5.info, where there are some interesting stories, actually mail correspondences, between web developers. Web developers means they were, in fact, developing the Web we see nowadays ;)
I.e. <img> tag we are used to:
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">
could be:
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
or
<A HREF="..." INCLUDE>See photo</A>
or
<INCLUDE HREF="...">
but finally devs decided to stick with <img>, which was already implemented:
We’re not prepared to support INCLUDE/EMBED at this point. … So we’re
probably going to go with (not ICON, since not all
inlined images can be meaningfully called icons). For the time being,
inlined images won’t be explicitly content-type’d; down the road, we
plan to support that (along with the general adaptation of MIME).
Actually, the image reading routines we’re currently using figure out
the image format on the fly, so the filename extension won’t even be
significant.
I don't know direct answer to your question, but I'm pretty curious about <link> tag, too. Finding answer would probably include some web archives digging.
There is a difference, at least from the W3C's point of view.
A <style> element introduces a block of CSS rules that apply to the current document. However, external style sheets are actually considered as whole documents related to the current page, and user agents are free to ignore such documents, depending on the type and media attributes of the link. For instance:
<link rel="stylesheet" type="text/css" media="screen" href="screen.css" />
<link rel="stylesheet" type="text/css" media="print" href="print.css" />
In this situation, user agents would typically only follow one of the links, either the screen one (for normal rendering) or the print one (for, well, printing). The idea was to preserve bandwidth by only downloading the appropriate resource, instead of fetching everything and filtering on the media type later.
This is mentioned in the specification:
When the LINK element links an external style sheet to a document, the
type attribute specifies the style sheet language and the media
attribute specifies the intended rendering medium or media. User
agents may save time by retrieving from the network only those style
sheets that apply to the current device.
They both have a basically identical meaning, and you have spotted a sort of inconsistency in HTML. The cause of this is that the standards were based on the implementations of different browsers. Different browsers came up with the attributes in the different tags, and the W3C just decided to keep some of the inconsistencies in order to maintain backwards compatability.
Elements that use src: script img iframe input video frame
Elements that use href: a link base
This might explain things, I guess: http://www.w3.org/TR/html4/struct/links.html
The <link> tag is used to "link" other documents to the current one, and describe it's relationship, or rel, with it.
You can also use <link> to link other things to the document. For example, favicons:
<link rel="shortcut icon" href="favicon.ico" />
Possible reason for link ref vs style:
link can only go on the head, where "Metadata content" is allowed, typically head,
style could not go in the body before HTML5 (now you can with scoped, but still not to external styles). Therefore, the choice between link ref and style src is arbitrary.
script, however, could already include an external script in the body before HTML5, so there had to be script src. But since it had to exist, why not allow it in the head as well (where script was already allowed), and disallow link rel=script to avoid duplication?
Apparently Tim Berners-Lee wanted everything to be done with <a: https://youtu.be/3QEoJRjxnxQ?t=901 !