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.
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
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!
I've seen several threads about reading contents, but nothing on writing to noscript.
$('body').append('<noscript><div></div></noscript>');
In Chrome and IE9 I get a noscript-element with a empty div inside like I expect, but in IE7 and IE8 I just get a empty noscript-element without the div inside.
Example: http://jsfiddle.net/cEMNS/
Is there a way to add HTML inside the noscript-tag that works in all browsers? What I need is to add some tracking code into a noscript-element at the end of the page, but the info I need isn't available until after document ready.
Edit: I'm getting a lot of comments on "why". It's some poorly done tracking library that requires this. We don't have access to the code to change it. Regardless, I find it interesting that it works in some browsers and not in others since jQuery was supposed to work equally in all browsers. Is it simply a bug?
Edit2: (2 years later) Adding a noscript on the browser doesn't make sense, I know. My only excuse not the question the task I had was because of lack of sleep, like everyone else in the project. But my rationale was that jQuery should behave the same on all browsers and someone might want to do this on the server.
Regardless of the tracking code, what you are doing (or are required to do) makes no sense!
Why? There are two cases possible here:
user has JavaScript enabled in which case the NOSCRIPT get's inserted into the DOM but is ignored by the browser (does nothing)
user does not have JavaScript enabled, NOSCRIPT does not get inserted and does not "execute"
The end result of both cases is that nothing actually happens.
Just an idea: You could try giving your noscript tag an ID, and then try to use native js.
for example:
$('body').append('<noscript id="myTestNoScript"></noscript>');
document.getElementById('myTestNoScript').innerHTML = '<div></div>';
I would claim that if it does not work with native js, it will not work with any library (feel free to correct me on this one).
I tried following simple HTML code:
<html>
<body>
<noscript>I'm a noscript tag.</noscript>
</body>
</html>
Then I did analyse this with IE8 (in IE7 mode) and his integrated code insprector. Apparently the IE7 checks are script allowed. If so he declared it as empty. And empty tags will be ignored. Unfortunatly I could not try that with disabled script option, because only the Systemadministrator can change the settings (here at my work).
What I can assure you, the noscript does exists. If you add
alert($('noscript').size());
after the creation, the result will be 1.
I"m wondering if anyone can give me some insight into a really strange IE9 issue I've been struggling with.
I'm finishing up production of a site for work - it works well in ff/chrome/ie7/ie8 with no script errors.
On IE9 the last step of the application causes the entire tab to whitescreen with no script errors or warnings. (changing the document mode to ie8 will fix the problem but is obviously unsuitable for production)
Unfortunately the site pretty complex with a ton of ajax, and in-page scripts so I can't really post the relevant code easily. I'm more trying to figure out how to diagnose this.
I've checked the IE error logs and they are empty. Web developer tools tells me nothing. The site is not using any plugins (Flash/Silverlight, Ect. ) just javascript w/jQuery.
There is a PDF being displayed in an iframe around the step where it fails - but a nearly identical pdf is displayed in the previous step (using the same method) without problem. The code fails around a call to the jquery UI window but I can't seem to get the exact line.
If anyone has a clue how to try to diagnose this further I'd really appreciate it. I can keep hunting for the bug but I've never seen this kind of behavior before and just am not sure what I am looking for.
Thanks for all the input on this. Sorry I got completely overwhelmed by a few projects at once so I wasn't able to post updates on the debugging steps.
It took forever but I finally realized that everything was crashing when I closed the dialog containing the first PDF.
One of my helper functions was opening the dialog and automatically destroying the contents on close. Normally this works fine as I'm either removing a div containing the page fragment, or the iframe.
In this situation I had a page fragment loaded into the dialog which contained some buttons and the pdf iframe. I called the .remove() method on the parent element containing the iframe rather than the iframe itself. For some reason this seems to work fine in every other browser - but in IE9 it pretty much kills the page rendering without any warning or message.
I strongly suspect that the culprit is the adobe plugin but I'm not entirely sure.
Here is the fix-
Html:
<div id="container">
<iframe src="loremipsum.pdf"></iframe>
</div>
Javascript:
//Ruins my entire week
$("#container").remove();
//Works as the pdf is removed directly
$("#container").find("iframe").remove().end().remove();
I ran into the same issue on IE11 while trying to remove an iframe in a div with AngularJS. Removing the iframe first would just cause the same issue, so I navigated the iframe src to a new page (about:blank) first, then removed the div which worked. Hopefully this helps someone with a similar problem.
Pseudo-code below:
$ctrl.iframeUrl = 'about:blank'; // change the iframe url here
$timeout(function(){
$ctrl.removeIframe(); // remove the iframe here
});
As a thing to try - see what's in the IE9 DOM viewer after it whitescreens. There's a decent chance that most of the stuff is there and just not rendering properly (or having something else rendered over it). At the very least, knowing whether it's losing a ton of stuff out of the DOM or not should give you some useful data.
Apologies but this is not a programming question, but it may have a programming answer.
For some reason my site, http://pctools.alwinsights.com will not display properly in IE (I'm using version 8) but it's fine in firefox and chrome. The content does not appear in the centre of the screen in IE and also generates two JS error messages while the pages are loading.
I've tried enabling Active X and Scripts in the security settings but with no joy. I've also looked around the net but cannot find an answer, well not one that works!
Unfortunately I know nothing about javascript so really don't know where to start with the error messages that are generated.
Any help appreciated.
regards
Nigel
Update:
OK initial error has gone, I'd screwed up with a directory name - apologies.
I've found out that if I disable the option to display the last twitter feed in the wordpress theme it loads OK. So it is the JS code in a php script called thememx-document.js that is causing the error. The code generating the error is "var twitterHtml = jQuery.cookie(twitterCookieName);" It says it's charcater 4, which is a space but I don't understand this.
I can live without Twitter on this site but it still leaves issues as to why content isn't centred nor the pop-up ad is not showing (compare to Firefox) but this may not be a programming issue that warrants a question on this site.
Thanks to all for your comments and input.
Nigel
Start with valid code; a validator will pick up lots of problems. Among yours is content before the Doctype, which triggers quirks mode. Quirks mode causes browsers to emulate bugs in ancient browsers and become much more inconsistent with each other. One of the emulated bugs in Internet Explorer breaks standard centring techniques.
for not properly disply-- its the problem of CSS ...IE7 and IE8 dosen't support css3.so you should simply make another css stylesheet for IE and call it on page only if someone visit your site using IE. and for other broswers it will show exiting style.
and abot JS error --you should check all your php coding and then fix it. its not JS problem. if you are not familar with PHP coding then i am here to offer my free service to you or anyone else. i will help you as i can.
First, having problems with any version of IE is expected and the norm. IE is the worst browser on the planet.
You have a link element on your first line. Links belong inside the head element. Placing it on the first line throws IE into 'quirks mode' and then IE becomes even worse than it normally is.
Good.
OK, maybe your site has to work for IE. 9 times out of 10, the problem is a terminal comma. The following is understood in real browsers but generates an unintelligible error in IE:
var x = [ 1, 2, 3, ];
The tenth time (in my experience), it's string indexing.
var x = "abc";
var c = x[2];
In a real browser, c is set to "c"; in IE, another unhelpful error message.
If this helps, remember: in IE, it's very important to create as many circular dependencies as possible. That is, attach to DOM elements JavaScript functions that have references to other DOM elements. IE fails to clean up such dependencies when the user leaves your site and so leaks memory. Once it leaks enough memory, IE slows and eventually freezes the OS and the user learns a valuable lesson: don't use IE. (Microsoft has a good page explaining how to do this although, inexplicably, they recommend against doing it.)