Not surprisingly, this results in a blank sheet out of the printer after printing the contents of the last table .(I’m dynamically generating my tables through php.)
Apparently not using right keywords in SitePoint search as I suspect this comes up often.
I thought about using <div class=“kludge”></div> and doing my page break on that (coding such that I do not generate this div after my last table) but the css doc site says that I can’t use an empty div.
Along those lines, though, a thought is to <div class=“kludge”>kludge</div>
.kludge {
page-break-after: always;
color: transparent; /* is there such a color value? */
background-color: transparent;
}
I don’t know what says you’re not allowed to use an empty <div>, but I’ve not come across that rule before, and it’s pretty common as a CSS hook, so I don’t see anything wrong with it.
A more elegant solution might be to have something involving :last-child or :last-of-type and page-break-after:none to override the usual rule - without seeing your code structure and knowing what restrictions there are on it, it’s difficult to say exactly what the rule needs to be, but hopefully that can give you a useful start in the right direction.
I know I’ve printed more than one web page that had a last sheet of one or two “nothing important” lines, and cursed under my breath while putting an otherwise good sheet into the scrap pile. Frustrating!
IMHO the main thing is to get rid of all the “web only” stuff and not break “heading groups / tables” unless absolutely unavoidable.
I say that because I’ve printed more than one web page that had the “H tag” at the bottom with the content on the next sheet, or worse, the TH and maybe a few TRs at the bottom with a bunch more TR’s on the next sheet. Aaarrgh!
So you wouldn’t be alone in having poor print CSS by any means, and at least you bothered to have one in the first place which is more than some sites.
</rant>
Anyway, if you’re getting only a blank sheet it’s probably an annoyingly small thing like a single newline. Can you do some custom tweaking like remove something else just to get it to end a wee bit sooner? Maybe slightly smaller padding/borders/margins somewhere?
Mitty, I don’t think you’ve read the question properly. The new page is being caused by page-break-after:always on the final element. No amount of tweaking or nudging is going to solve that, you’ll still get the blank page even if the table stops halfway down the previous page!
Assuming your tables are not nested within parent elements then you can set the last one to not print the extra page (which only seems to be happening in chrome anyway).
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title>Untitled Document</title>
<style>
table {
border: none;
page-break-after: always;
}
body > table:last-of-type{page-break-after:auto}
</style>
</head>
<body>
<table>
<tr>
<td>test</td>
</tr>
</table>
<p>P element here for testing only - has no use in the demo</p>
<table>
<tr>
<td>test</td>
</tr>
</table>
<p>P element here</p>
<table>
<tr>
<td>test</td>
</tr>
</table>
</body>
</html>
It does depend on your structure but assuming there is some conformity the above method should work (IE9+).
body > table:last-of-type{page-break-after:auto}
[/QUOTE]
That did it. Originally I thought that body > table was a typo -- that you meant body { table. Silly me.
But I have not seen that > notation. A quick google check tells me it means "child of". For grins, I removed the "body >" and it also eliminated the blank page.
So what fixed my problem was the ":last-of-type", right?
(For my further education, why did you choose to use the "child of" notation in this case?)
Thank you very, very much.
Regards,
grNadpa
So what fixed my problem was the “:last-of-type”, right?
Yes that was the main fix and found the last table element in the html. We could have used :last-child also but it would fail if there was another element after the last table.
I used it in case you had nested tables because you obviously wouldn’t want a nested table to produce a page break in the middle of a larger table. The child combinator (>) ensures that only tables that are direct children of the body will be affected.
