I'm wondering about using the print option by using JavaScript in Firefox.
I have a page that has a print link:
print
I also have followed the instructions on About Javascript's print button page.
The problem is that when I try to print a page under Firefox, I get a four page PDF preview with missing content:
The first page is empty,
The second will start with the content that should be on the third page, and
The third and fourth pages are empty
I tried using Chrome, and it works as expected.
Any ideas?
The best way to get a consistent printing behaviour is using a print stylesheet. This defines exactly, which content should be printed how, because browsers differ strongly on that matter. Some browsers have problems with certain markup (e.g. floated elements).
You can find a very good article about print stylesheets on A List Apart that should be very helpful for you.
Certainly there might be other good articles which are newer but this ALA article is so fundamental that it still is worth reading even though it is 10 years old - which is like stoneage for web-content;)
It's all because of Firefox inability to handle different container styles. I use UIkit and fixed the issue by adding the following code to my CSS file:
#media print
{
.uk-grid {
display: inline !important
}
}
You might want to set "display: inline !important" for classes you use.
Related
I'm writing my own site as a hobby (any html/css/js I know is self taught), but I've run into a issue that I can't seem to really understand (and thus I don't know how to fix it). I can't handle/fix this by myself unfortunately.
I tried taking away as much unneeded code as I could, reducing the site to the bare minimum where it still exhibits the unwanted behavior. I'm sorry for amateurish/hacky code, I'm not doing this professionally after all.
Here is a jsfiddle showing the code. It exhibits my wanted behavior: Click on any of the "Folders" and it expands and shows the "content". So far, so good.
If I now load the exact same code onto a site (I'm using netlify here), it still behaves as I want it to: Netlify link
If however I access it on a mobile browser (for reference I tried it on Google Chrome, Firefox and Brave browsers, all on Android) I get some behavior that I don't want:
If I expand one Folder, it works as intended, but if I expand the second folder as well the Folder name and its contents seem to change font size (they get noticeably bigger). If I close the normal one and reopen it it also changes size. For reference,
this is what it looks like.
It almost seems like me switching the display property to block changes the font size to something else, but I only defined one font size in the whole css.
I really don't know why this happens and I'd appreciate any help that explains it or points me in the right direction.
Thanks.
Edit: I managed to contact a third party who tried the site on their phone (iOS) and there the site did not exhibit the same weird/unwanted behavior. I'm not sure what exactly to do with that information.
I might have finally found a working solution to this weird and unexpected behavior. In your CSS, in the body section, add the following rules:
font-size-adjust: none;
text-size-adjust: none;
-webkit-text-size-adjust: none;
Those rules do not really have wide-spread support, apparently, and might change or their support get dropped at some point. One works only for Firefox, the other only for Chromium-based browsers, and yet another seems necessary for legacy Chromium-based. See:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust
https://caniuse.com/?search=font-size-adjust
https://caniuse.com/?search=text-size-adjust
Only with all three of those rules did I successfully prevent this font scaling for mobile Chromium, mobile Firefox Quantum (the old Firefox <=68 was not affected), both on Android, and for Chromium mobile mode on a Linux desktop. At least as far as my tests indicate.
Although I still fail to understand how and why such a rule would even be necessary: There definitely is no other conflicting rule in your example to affect rendered font size. My very wild guess would be that, under certain circumstances, some mobile browsers do not apply font-size rules correctly to hidden elements, causing this obscure cascaded font scaling.
Not at all the answer, but the described behavior can be reproduced even on a computer (Ubuntu Linux in my case; non-android device) using the given netlify link in Chromium, when using the mobile mode in Chromium DevTools. Maybe by reproducing it this way, somebody gets behind the cause of this behavior.
Upon opening the second folder, the font-size is indeed set to something 42.073px or something similar, depending on the responsive mode selected in the mobile mode. This is only shown in the "Computed" tab of DevTools, but there is no rule for this size in the "Styles" tab. I don't see any apparent cause for this text size change, sorry.
A few notes, however, on your HTML code (though none of the below seems to solve your problem):
Better put the <script> tag inside the <body> tag, right before the closing </body>. Or put it inside the <head>, but then make sure it get executed after page load. Outside <body> or <head>, your <script> is somewhat in limbo – unexpected side-effects included.
Similar goes for your <meta> tag. Put it inside the <head>.
For valid code and to reduce and even avoid unexpected side effects, surround your complete HTML code with an <html> tag, and define a doctype, e.g. <!doctype html> at the beginning of your HTML. Validate your HTML, for example here: https://validator.w3.org/#validate_by_input
My website system is running on chrome 37+ and using Angular.js and bootstrap.
For some reason, I can't print my website.
When i try to print my website (using the browser print dialog), I usually get a blank print preview ("can not load print preview"). Sometimes it is not blank, but not really show my website.
I tried to run my website on some google chrome versions and some computers and it is not working.
I have been searching for reasons, but can't find one that will fix this issue.
Let my know for reasons for this issue. Thank you.
Chrome actually does have emulation of printing. See
You'll find this in a tab adjacent to console within developer tools. By enabling CSS media on print, you'll see your site with any print media applied. Once enabled, you may use the element inspection as usual to see how those extra css rules affect your site.
In particular, bootstrap will remove any background, and run a bunch of defaults across many typical elements.
Also, see this answer https://stackoverflow.com/a/21156904/2923245
I have an annoying white space below footer problem, and no matter how long I have searched for the answer I cannot find it, because it doesn't seem to be anything I can do in CSS to solve the problem. Also, the problem is not on every page... it arbitrarily selects (seemingly) random pages within the website, which made me think that perhaps it is happening as a result of some javascript code that I cannot seem to locate as being the offending party.
Anyway, after hours of scrolling through websites, I decided to load the website without javascript and sure enough the white space disappeared. As a somewhat novice programmer, I'm not really sure what to do next. I put
<div class="clear"></div>
right before in my header, and voila, it worked... no more white space on any of the pages. So technically, I guess this resolves my problem, at least visually, but since I'm a novice, I have no idea what the potential repercussions are for this? Is it okay to leave it? Could I try something else? Does this problem sound familiar to anyone? Many thanks in advance for your help! I don't know if you'll need more info than this.
Just to be clear, I'm developing a child theme in Wordpress off of someone else's theme. The website is a multisite, and the other site on the multisite doesn't seem to be broken at all, despite having nearly all the same elements. One of the few differences is a Contact Form 7 form where they each have their own instance of a CF7 form. When I attempted to add some javascript to the CF7 form, I believe that's when it broke. Since I only added it to one website (within the form itself), I think that's why only one website broke with the white space underneath. Simply removing the code wasn't enough.
By the way, I should add I have had this problem with this website before, and my (weird) solution at that time was to rename the links of the pages where the white gap was showing up... and sure enough, it worked. Obviously, as my site grows backlinks I don't want to keep doing that.
So, is my rudimentary fix enough?
As APAD1 said, the <!DOCTYPE> declaration must always be the very first element in the HTML document, otherwise it will have no effect! The fact that placing <div class="clear"></div> before the <!DOCTYPE> declaration seemed to fix your problem indicates that the white-space was somehow the related to or caused by the browser defaults for that particular HTML rendering mode.
Also, what browser are you using? You're not using Internet Explorer, are you? Different browsers or even different versions of the same browser may render your page differently.
As for the <!DOCTYPE> declaration, it is needed to indicate a particular layout mode the browser should enter.
In Internet Explorer, for example, the omission of a <!DOCTYPE> declaration may cause the browser to enter Quirks mode, as opposed to a Standards-Compliance mode. Note that <!DOCTYPE html> is used for HTML5 documents, whereas something like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">`
...is used for HTML4. The (X)HTML doctype declaration is used to put the browser into a particular layout/rendering mode. Different rendering modes result in different CSS default styles. It is likely that some combination of CSS rules are resulting in the unexpected white-space.
I suggest you become familiar with (or at least play around with) Firebug (a FireFox extension), the Webkit Inspector ("Developer Tools") that comes in Google Chrome and Safari, and/or the IE Developer Tools. All of these tools allow you to "inspect" elements in the Document Object Model (DOM) for your webpage. These tools will even let you view and modify the HTML source code and CSS rules for elements in the DOM. (Please be aware any changes you make with these tools will not be saved and therefore are not persistent!) This means that using one of these tools, you can select your footer element and view its applied ("computed") CSS styles. This is especially helpful in not only troubleshooting your webpage or WordPress theme, but also in developing it.
So, to sum up:
If you don't place the <!DOCTYPE> declaration as the first element, then you might as well omit it altogether.
The <!DOCTYPE> declaration places the browser in a particular layout mode that has certain CSS defaults.
A combination of CSS rules is likely resulting in the unexpected white-space.
You may use browser "developer tools" such as FireBug to inspect (and modify) your webpage.
Okay, this is resolved (as of right now). The problem was a plugin conflict that was writing javascript to the footer. It only caused a problem when I added javascript to the Contact Form 7 plugin.
To resolve the issue, I edited the HTML in firebug as you suggested, Alex. Once I found out the offending plugin I disabled the conflicting scripts.
Thanks for all your help, guys. This is resolved.
I'm currently building a site where I'm using fonts.com to display a custom font for headers and subheaders. The font gets loaded via fonts.com javascript link and is then referenced in the CSS file as:
font-family: 'MyFontFromFontsDotCom';
It works fine and performs well. In IE8, however, the browser crashes after the font gets loaded (it never loads fully though) and the site. When I hit the "stop" button in the browser, the site gets rendered with the correct font.
I have a modernizr 2.6.2 running aswell which is referenced before the fonts.com javascript. When I remove the fonts.com javascript, the site runs just fine.
The fonts.com javascript reference is at the bottom of the body tag and the modernizr is at the head tag. I tried moving them around without any luck.
Has anyone experienced the same issue?
Thanks in advance.
I came across this issue when I was cross browser testing a site on IE 8. I fixed the issue by using the 'Non-javascript' (CSS) option.
You can get to this by going to the Manage Web Fonts section on fonts.com, selecting your project and then clicking the 'Publish Options' link.
In the window that pops up there is a tab for 'Option 2: Non-Javascript', this will give you a code snippet for CSS instead of Javascript. You should paste this in the head and then remove the Javascript snippet.
I know an answer was already accepted for this, and it is perfectly valid solution (using the CSS option instead of the Javascript option), but there is another possible solution if you do need the Javascript option (I like to have the -active classes added to my document).
It turns out there is a known issue with the fonts.com Javascript on IE8 when there are unclosed tags. So if you have a situation like:
<div><span>March 2014</div>
This will cause the fonts.com Javascript to cause troubles.
So find and fix unclosed tags with the W3C validator!
This problem occurs in Firefox and Chrome, but Safari is fine. IE8, however, in compatability mode or not, doesn't load the overlay over the top (it just sits at the top, scrolling the content down - although I guess this is because the overlay is at the top of the markup).
It also doesn't show the image I'm attempting to show, but shrinks the overlay loading image to nothing in the top left of the screen. I am using the standard colorbox-min and the CSS that goes with that.
Inspecting the markup in the IE8 dev tools seems to hint that the content is not actually loaded into the cboxLoadedContent div.
$(document).ready(function() {
$('a[rel="preview"]').colorbox(
{
photo: true
, maxWidth: '95%'
, maxHeight: '95%'
, photoScaling: true
}
);
});
basically the page is a list of media images and when you click one it gives you the preview and allows you to scroll through ones on the page
well at least it does in FF took a little screenshot as it was shrinking the overlay thingy http://dumpt.com/img/viewer.php?file=7s2zwoxozzf7666h0fzc.png
Anyone have any ideas?
I expect my explanation is not great, so maybe I could take a movie of it or something if needed.
Is your code wrapped in a ready function? I've seen instances where code that works in FF/Safari fails in IE because IE seems to load the DOM more slowly. In those cases it almost always turns out that I've failed to wrap the code in a ready function.
$(function() { // the important bit
$('.colorbox').load('...').colorbox();
});
Try an XHTML strict doctype...?
I've experienced the exact same symptoms - but in my case it extended to all browsers.
One cause was that I didn't include the CSS file that I use for pages that use colorbox.
Another cause was I updated to the newest version of jQuery, but didn't upgrade colorbox. (Also, if you update your jquery include, make sure that you also update your jquery vs doc - if you're even using it).
Hope that helps.
Search through your colorbox files for this:
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
There will be several instances of it, each pointing to a png. Make sure the path to that png is correct, then test it again.
I'm pretty sure I had this exact problem at one point, and fixing the paths was all I needed to do. However, it's been a while so my memory is a little fuzzy.
I had the same issue. I also had a problem with the image being only 10px wide due to IE not liking CSS max-width being set to 100%. To alleviate the problem I add the following to my CSS.
.cboxIE img
{
max-width:none;
_max-width:none;
}