Given a document with h2 elements followed by p elements, I some times get a page break between the h2 and the first p, when using wkhtmltopdf.
I have tried:
h2 {
page-break-after: avoid;
break-after: avoid;
}
h3 + p {
page-break-before: avoid;
}
which I think should avoid page breaks after all h2 elements, and avoid all page breaks before a p element that follows a h2.
Neither of these seem to have any effect. Perhaps I am misusing them.
What does seem to work is page-break-inside: avoid;, but that means I have to wrap the header and first paragraph in an element and apply that style to it. Perhaps that is the only solution right now, but it causes me some other problems.
Can anyone offer any help?
From: http://madalgo.au.dk/~jakobt/wkhtmltoxdoc/wkhtmltopdf_0.10.0_rc2-doc.html
The current page breaking algorithm of WebKit leaves much to be
desired. Basically webkit will render everything into one long page,
and then cut it up into pages. This means that if you have two columns
of text where one is vertically shifted by half a line. Then webkit
will cut a line into to pieces display the top half on one page. And
the bottom half on another page. It will also break image in two and
so on. If you are using the patched version of QT you can use the CSS
page-break-inside property to remedy this somewhat. There is no easy
solution to this problem, until this is solved try organising your
HTML documents such that it contains many lines on which pages can be
cut cleanly.
I think that means page-break-inside: avoid; is the only option that works right now (although I am using version 0.12.1.1).
Related
I'm trying to print a web page I created.
I also created a style.css with specific rules for print.
I have some div boxes representig comments I need not to be split inside among pages.
I added this property:
page-break-inside: avoid;
This worked for the the shape (the bubble is correctly not split inside), but the box-shadow is still split among pages.
IMAGE
How can I solve this issue?
My problem is when I try to add margin bottom to all elements of columns:2 list, i've added margin-bottom:5px for spacing but for some reason it doubles the spacing. One in the third element bottom and the fourth element top (which gives me the problem)
Is there any solution for my problem?
I have just hit this bug in Chrome.
With a little investigation, it seems the bottom of the last <li> in the first column gets placed at the top of the 2nd column.
The solution was to apply the follwing to the <li>'s:
display: inline-block;
width: 100%;
Hope this helps, someone else.
I recently had a similar issue too and the solution is in MDN docs.
.card {
break-inside: avoid;
page-break-inside: avoid;
}
And an example from MDN.
Actually it was bug inside an old version of Chrome.
I tried Firefox and Chrome current versions; neither of them had this problem.
I'm having an issue with text overflowing within a column when an inline image is aligned left or right. Its hard to describe so I created an example page at http://alaskalegion.com/dev/test.php
This only occurs in IE6 and IE7. Any thoughts on how to fix this?
I'm using fckeditor on the backend which is generating these.
You need to make sure the p tag wraps around the image so that other paragraphs are above and below it. I can´t test it right now, but I usually use overflow:hidden on the surrounding block (the paragraph) and I think for IE you need something like zoom:1.
By the way, can´t you get rid of the inline 'align:left' and replace it by css in an external style sheet like:
#center-column p img {
float: none; // if still necessary...
}
#wide_column p img { // I don´t know what the id of the wide column is...
float: left;
}
(I don´t know if you need the p selector, I'm only trying to target the right images without seeing your code)
Is it good to add line-height in body{line-height:1.5} or it would be better if i add separately for tag by tag like p{ line height:1em} etc.
Edit:
body {line-height:in em} create problem with if we put image with float inside
Edit: 24 April 2010:
If i have to add different line heights to elements
like
p {line-height: 1.4}
h1 {line-height:1.6}
h2 {line-height:1.2}
ul li {line-height:1.1}
then shouldn't i use line height in body {line-height:1.4}
if body {line-height:1.4} and h1 {line-height:1.6} then what would be line height for h1?
It just depends. If you put it in the body then you get to be lazy and not worry about ever doing it again, but your going to lose control because everything on the page will have the line-height set to 1.5. Whereas if you declared it in each tag, you gain lots of control, but will have to do more work.
Personally I would go for the tag-by-tag solution, but I'm a control freak, so...
A word of caution on putting line-height on the body tag:
If you specify a height in percent, you would intuitively expect to enlargen / shrink all line-heights (e.g. 50% shrink to half, 200% duplicate space, 100% nothing happens).
body {
line-height: 120%
}
This is not the case. For paragraphs and normal-sized text it works fine. But for headings it's a disaster, since the same line-height as for normal text gets applied... See what happens here: https://jsfiddle.net/11jgwzzu/ .
It works, if you use for example 1.5 instead of 150%.
With this in mind, I think it's quite okay to use something like this:
body {
line-height: 1.61 // Golden Ratio
}
to make the entire page a bit more spacious. You can still overwrite this behaviour for some specific elements if you want to, but I often find I don't even have to overwrite it since I think line-height: 1.61 looks pretty good everywhere.
The obvious answer is specifying it once in the body is less work (and overhead).
There is a definite CON: if you use a unit (like 'px') in the line-height, and you specify it on the body, it will be used like that throughout the page. This may create crazy results with fe big page titles overlapping eachother or tiny aside text getting ridiculous whitespace between lines. If you dont use a unit, and specify it nowhere else, the vertical rythm of the page becomes messy.
Read this: http://www.alistapart.com/articles/howtosizetextincss/
Specifying a unit (in this case, px) when setting the line-height
enables the value to be inherited throughout the page. If a unitless
line-height had been specified, the multiplier would have been
inherited, resulting in line-heights being rendered proportionally to
the text size, thus breaking the vertical rhythm.
It is common in websites to never use a unit on line-height, which is one of the reasons why the most websites look a bit messy, designwise. Just look at this page, already :-)
I would specify a unitless line-height on the body element, and use a unit-based line-height on a designated 'content' area where you know exactly what sort of content to expect (the 'content body').
*-pike
put it where it's appropriate
if you want line-height: 1.5 on everything within the body, put in on the body
if you only want line-height: 1.5 on everything in the main content area, put it on the div id="MainContent"
etc.
I'm trying to get a website to display properly in IE6 and IE7. Here is a screenshot of how it looks in IE6.
alt text http://img225.imageshack.us/img225/4779/screenshot20091006at239.png
IE8, Safari, Firefox, etc. all display this site correctly. Could someone give me a hint as to what is causing the distortion in IE6?
If you want to take a look at the page source, the site is: www.devaswami.com
Get the CSS from here.
You're using an auto-layout table for the navbar, and it has colspans. This confuses IE, which is not very good at working out how big tables need to be when there are colspans. It makes the table wider than you need, which makes your cells wider than expected, which makes the ugly yellow background show through and it doesn't line up.
To fix it, set the style table-layout: fixed; width: 970px; on the table element, and add one <col> element for each column, each with a width: ...px style that tells IE exactly how big to make each column. Then it can't make any mistakes (and also larger fixed table layouts render faster).
To fix it better, drop the layout table and use positioned divs for the nav links. You could then also lose the silly image slicing and have a single GIF for the whole header background with the photo and links positioned over the top of that.
(Also it is worth fixing the validation errors both in the HTML and in the CSS. You are using // as a single-line comment in your stylesheet, but there is no such thing in CSS; you will only confuse the parser into dropping rules.)
Ummm at a glance, you have something that is float left and you have a margin left on it?
#foo {
float: left;
margin-left: 20px; //20px in all browsers except IE6 where it will be 40px;
display: inline; //this will fix this issue
}
There's a lot of possibilities and it's hard to just guess based on the screensnap. However, one big step towards making IE 6 and 7 behave better is to declare the doctype at the top of the document:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
That's for HTML 4.01, you'd have to update it to match what you're specifically using if it's not HTML (i.e. XHTML). That alone helps with some of the basic problems, but not all of them. If that doesn't do it, Google "IE6 css hacks" and you'll find lots of potential information that may apply to your context.
Edit: I suggest you fix the errors related to missing/improper end tags:
Error Line 199, Column 194: end tag
for element "a" which is not open
Error Line 200, Column 49: end tag
for element "p" which is not open
Source: http://validator.w3.org/check?uri=http%3A%2F%2Fdevaswami.com%2F&charset=(detect+automatically)&doctype=Inline&group=0
After that's done we can deduce that it's not a markup related issue.
Original answer:
Try applying haslayout to every element and using display:inline on any floated element:
#nav li { display:inline; } /* the selector *must* be floated and have horizontal margins in the direction of the float. */
* { zoom:1; }
For anything that was fixed by the zoom:1, apply a width/height and that will trigger hasLayout.
Though it might be useful if you actually posted some source code.