I was just recently asked to add a print stylesheet to a site I've coded out and am baffled as to why Firefox is mangling the output. A print preview of the following page reveals what I'm referring to:
http://webreviewportal.com/ethicalmovers/newsite/aaem-customer-testimonials.php
When you try to print that page in Firefox, you get the logo on one page, part of the testimonials on the second (they get cut off), and another blank third page. I've tested this with moderate success in IE and Safari with no such issues. Thoughts?
Also, why does the text get cut off (as opposed to wrapping) when you scale the page to anything above 150%? Thanks in advance!
If you add "overflow: visible" to #content in print.css, it prints correctly in Firefox. Your overflow is set to hidden in style.css, which is why the text is getting cut off on one page.
I've not really experimented with print stylesheets yet, having not had the necessity nor curiosity enough. However, looking at the W3C's page on paged media, reveals that page breaks may have to be explicitly stated or allowed:
This section describes page breaks in CSS 2.1. Five properties indicate where the user agent may or should break pages...
Taken from: http://www.w3.org/TR/CSS2/page.html#page-break-props, 2009-07-27, 18:13
So it may be worth adding in the page breaks, or disallowing the page-break between the testimonials and the logo, by adding:
#leftcol {
page-break-inside: auto; /* although this may be the default value, anyway */
}
I think I remember Eric Meyer having issues with this sort of thing because of the 'float' property; but since you've already stated float: none!important; I guess you've dealt with that.
Related
We wanted some numbered lists and found this cool counter thing you can use in you css to have the browser calculate numbers for you:
ol.instructions {counter-reset:instructions-section;}
ol.instructions > li:before {
content:counter(instructions-section);
counter-increment:instructions-section;
}
The html we're making contains pages of instruction sets, each set numbered from 1,2,3 and so on. Only one set is visible at a time, when you click a header you show that set and hide the others.
It worked like a treat and we were sitting there with smiling faces until someone thought of testing it in Internet Explorer 8, where we ran into some epic Microsoft-style weirdness. When a set was brought up by clicking, all the numbers were zero (0).
I googled around and found this page - it describes the problem fairly well (it's a combination of using :hover and css counter logic used in hidden content), but gives a solution that is less than satisfactory - I would love to be able to keep using the css counters and just implement some ie8-specific hack that somehow makes the page update the numbers. I'm having a hard time finding other stuff on the internet about this problem.
My particular page will describe zeroes until I move the mouse pointer into the div that contains the numbered list, at which point the numbers will magically fix themselves. Is there something I could to "nudge" the page into believing that a mouse is hovering over the element? Or is there a more proper solution?
Ive had the same issue. I was able to fix it by using JavaScript to apply inline CSS of padding-left 0 (there was already no left padding) once the element was visible. This seems to make IE 'redraw' the element.
If, as is suggested, the "hidden" is causing a problem then you could try "hiding" the content by instead moving it off screen with this piece of CSS:
.hide {
position:absolute;
left: -1000px;
}
I've used the code example from the linked to document to show a possible solution here: http://codepen.io/akademy/pen/LDhGl
I've been setting up a very basic Wordpress site. All of the pages have a lot of empty space at the bottom. Pages with more placeholder content have more space at the bottom than the others.
I have been reading other threads from people with similar problems, and I can't fix the problem on my site using suggested fixes (the margin property in a certain div was often the culprit).
Check it out: http://www.hairofthedogproductions.co.nz/?page_id=5
My client wanted a totally minimal bare-bones site so I have collapsed post/page metadata, comments, and the sidebar. I just can't for the life of me get rid of the big empty space at the bottom.
Your main problem is in the comments template. I see you're using visibility: collapse to hide elements, but collapse is just for table elements, and if used in other tags it'll default to hidden. Plus, keep in mind that visibility: hidden hides elements but keeps them in flow. You might want to use display: none instead.
This will solve your problem, try it out.
#comments { display: none; }
Validate your page: http://validator.w3.org
I validated it and found about a dozen errors (some of them potentially serious enough to break the layout of the page, such as an unterminated tag).
When inspecting the source in Chrome, the element in the blank area was the HTML tag itself, which might indicate an overall failure to determine the correct document structure--the parser tries but can't always determine what you want it to do when there are malformed tags.
Just apply overflow:hidden on your main wrapper then it will remove all blank space at the bottom
#main {
overflow: hidden;
}
I have a named anchor tag:
<table id="search_results" name="search_results">
I am linking to this like so:
pagename.php#search_results
This is working in Firefox and chrome, but not IE (8).
I have tried using an <a> tag as suggested in some other posts. I have also tried to give the search results table the css:
display: inline-block
as suggested by one of the commenters on this article. My table always has content as well, which the article suggests can be the reason for IE rejecting it.
I'd be grateful for any suggestions.
Many thanks
That's how I was motivated to search for a different solution:
Added text was inappropriate for the display and the non-breaking space caused an extra line space to appear between the paragraphs. This could have been corrected, but the multi-MB pages would have required a lot of manual work.
The pages, developed with iPage, can be viewed here: www.theUB.org
I've been told by several professionals that such long pages are usually avoided in web site design, but these pages (with many named anchors and a "point & click" Table of Contents) seem to work well for this 2000-page public domain text.
One more disadvantage of the non-breaking space solution:
This online text needed to be read correctly by computer screen readers. Some people have commented on other blogs that screen readers voice the non-breaking space (or added text).
(Note the added decimal point after the paragraph numbers - this was necessary to prevent screen readers from voicing the merged paragraph number and first word of paragraph.)
Couple things:
IE8 does not support inline-block ;)
When you tried the a anchor, which is probably best, was your code something like
<a name="search_results"></a>
<table name="search_results" id="search_results">
</table>
The <a name=""> method is pretty much universally supported.
Firstly, using named anchors to navigate the page does what it says. You have you use a named anchor (<a> tag) to do it. Some browsers support it on non-anchors, but this is not universal and should not be relied upon - as you have discovered.
Secondly, are you sure you page is long enough? If the thing you are trying to link to is right at the bottom of the page, it won't display at the top of the viewport as you might expect, since there is nothing below it to display at the bottom of the page.
Thirdly, check that you did the named anchor correctly. You should be doing something like this:
<a name="search_results"></a>
<table name="search_results">
...
Regarding named anchors that do not require text:
Others have suggested this "workaround" for IE8: insert a "non-breaking space" character if no text is required ( ).
However, I also discovered that resetting my IE8's View/Zoom from 125% to 100% also activated the anchors that were not corrected with the "non-breaking space" solution. IE8's View/Text Size is not part of this problem.
Note: Large, text only, HTML pages were being tested: (font face="Verdana" size="+1"). These HTML pages displayed correctly in Firefox 15.01 without regard to View/Zoom,Text Size settings.
I've got this working by adding some text inside the anchor, like:
<a name="search_results"> </a>
This appears to be another solution to the IE large file load delay: create a smaller HTML file which links via HREF to the large file (or to a bookmark (named anchor) in that file).
This test has been tried multiple times with the IE direct load of the large file always causing a long delay, but not when the user clicks the link in the small file to go to the large file.
Perhaps, IE is analyzing the primary file to see if it had already been loaded into the cache.
Note: This HTML file being tested is 11 MB (an entire book with many bookmarks and links to those bookmarks from other parts of this very long HTML page).
I faced the same problem on IE, Edge and chrome,
and I think the problem is because the encoding and decoding on the name attribute
so I did a workaround solution, take a look
anchorElem.on("click",function() {
var href = $(this).attr('href');
var scrollEle = $(".tocContent").find('a[name="' + href.substr(1) + '"]' + ', a[name="' + decodeURIComponent(href).substr(1) + '"]');
if (scrollEle.length > 0) {
$('html, body').animate({
scrollTop: scrollEle.offset().top
}, 0);
return false;
}
})
hope this help you
and happy solving browser compatibility issues
I'm trying hard to give full HTML header/footer printing capabilities to our Mediboard project.
Long term, I know that CSS3 Page Media module will fulfill my needs, but that's two or three years away at least.
So I tried to make it work with CSS2 capabilities, and it almost works as you can see on this printable document. Yet, I still have a limitation on the footer where the content prints under the footer (see pages 3-4 with Print Preview).
Though I'm pretty sure the padding-bottom of the div.body used to make it work in Firefox 2.
Anyway, does someone have a tricky clue to help me on that problem?
EDIT:
To give more details, we currently have headers and footers by using elements positioned with position: fixed, with top:0 or bottom:0 depending if it is a header or a footer. This works well, and when printing, these elements are repeated on each page at the right position (see the "printable document" example). The only problem is when a page break occurs, the text is drawn behind these elements (see page 3/4)
EDIT2: Updated the document's URL
It looks like CSS2 has a #page rule in which you can define your page size and a margin:
#page { size:8.5in 11in; margin: 6em 1em 2em }
-or-
#page { size:auto; margin: 6em 1em 2em }
Unfortunately I don't have time to test it, but I would love to know if it works. I could use that.
I like what you're planning with the header/footer. Good work :)
From my experience, page-break doesn't work within an element. If an element such as [p][/p] spans two printed pages, the HTML code isn't aware where the break happens between the pages. This is because the user may sets their own printer margins be they 1 or 1.75 inches or some other value. Actual printer margins cannot be set via CSS. CSS can only set the margins and padding to the HTML page -- to the "printer's" defined margins. No information about printer settings, such as margins, is sent to browser. This explains why content is being underwritten under the header since the browser has no idea when the page feed happened. The easiest solution is just to have the header information on the first page but, that's not what you want. The brute force approach is to insert page breaks [br style="page-break-before: always;" /] within the paragraph at the appropriate place but, this isn't practical for a large number of documents. Also, subtle differences between printers including those from the same manufacturer differ subtlely - for exanmple, one print may print the content just fitting on one page, the next printer may have the last line on the next page even though both printers have the same margin settings. However, for tabular information ([table][/table]) assigning such CSS becomes easy to keep tables together. I'm speculating that one could count characters on a page and dynamically insert page breaks via javascript (easy, if you used JQuery) to approximate the brute force approach.
You will want to implement media types most likely. Please see http://www.w3.org/TR/CSS2/media.html for more information. You can have one CSS sheet that does not have a floating footer for printing, and the other for the screen.
<LINK REL="stylesheet" TYPE="text/css"
MEDIA="print, handheld" HREF="foo.css">
That is an example.
You can also consider making the footer invisible on the printed page if you do not need it.
I know this kind of question must get asked all the time but I haven't found a solution for my problem yet.
Using FF, Opera and the IE that is on Windows 7 (can't remember what it is), the page looks exactly as it should, but using IE7 on Windows Vista, there is a gap between my navigation bar and the rest of the page which frankly makes it look stupid, and the illusion of tabbed pages is lost.
I have a reset stylesheet to reset all the elements to have no padding, margins etc and FF, Opera and the IE on Windows 7 produce the page as they should, it's only IE7 (and I'm guessing earlier versions of IE) that don't.
Here are 2 screenshots showing the problem, the first from FF/Opera/IE on Windows 7:
This one is from IE7 on Windows Vista:
alt text http://img43.imageshack.us/img43/7558/figarosiegap.jpg
And here is a link to the actual website in question: Figaro's Ristorante
Any ideas anyone?
Thanks for your time.
I've run into this problem a bazillion times. Add this to your CSS:
#header img { vertical-align: bottom }
There's a funny bug in IE up to and including version 7 where it will treat some whitespace (an empty text node, really) as a real text node, and align the image as if there was text in the element as well.
Another option would be to declare the image as a block level element:
#header img { display: block }
This CSS is safe to add to your global file, it will not interfere with how other browsers render the page.
The IE on windows 7 is IE8
I've taken a look at it using IE7, and the gap appears to be because of the image in the 'header' div. If you look at it with a tool like IE Developer toolbar you can see the boundaries around the objects on the page.
Sorry i cant paste an image but i'll try to describe it:
there is a #text element after the image which is being forced onto a new line by IE7.
if you change the style on the img to include
float: left;
This fixes the problem for me.
Hope this helps!
(Let me know if you need more clarity)
The gap is part of the text line where the menu image is, because the image is an inline element so it's placed on the baseline of the text line. The gap is the distance from the baseline of the text to the bottom edge of the line, i.e. the space used by hanging characters like 'g' and 'j'.
Simply adding display:block; to the style of the image solves the problem. It turns the image element from an inline element to a block element so that it's not placed on a base line of the text but as a separate element.
I've run into this problem a thousand times, and finally, after using overly complicated fix after fix, the answer is simple! (At least when <img>'s are involved.) In the div that is producing a gap under it, add 'overflow: hidden;' to its css; you will need to set its height, of course. So, if your div is 39px high, this will keep it at 39px high, ignoring the extra whitespace IE loves to put under <img>s
Hope it helps.
There's not much useful information (html or pictures that work) in this question. So, here's a random guess.
I've had situations where a line-break or spaces between elements can cause vertical space between elements. Try placing the closing and opening tags immediately next to each other and see if this corrects the issue.
Different browsers all have different default margins and padding. In this case, I'm guessing IE7s defaults are throwing you off. There are two general solutions to the problem. You can set your own margin and padding at the html, body level:
html, body {
margin: 0;
padding: 0;
}
or you can use IE conditional comments to load sepearte stylesheets for different versions of IE. Last I checked, the conditional comments were considered a better solution because browser defaults do provide some usefulness.
Jason is correct that it's a bug in how IE handles whitespace in the html... treating it as a text node. Though I don't think it's unique to images. I believe I've seen this behavior with divs as well. As a global change you may try applying vertical-align:bottom to both images and divs. Though I don't know what mayhem that may produce.
But the quick and dirty fix is to just remove the whitespace. Kinda sucks, but change stuff like this:
<img src="blah" alt="" width="5" height="5" />
<div>blorg</div>
To this:
<img src="blah" alt="" width="5" height="5"
/><div>blorg</div>
I warned that this is quick and dirty. But it works.