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!
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
This is a shot in the dark whether or not anyone can help determine the source of this bug.
It was brought to my attention today that some JS in our web-app causes IE9 to replace the text-node content of an anchor tag, with the href attribute content. This completely breaks the styling of the top-level navigation. The curious thing, is that it only happens on one page in the application.
I've seen other answers to related questions and jQuery bug reports saying that IE9 does do this behavior when the href attribute is programmatically changed. The solution in those cases was to save the innerHTML before and after the change, and replace it with the original content. However, I don't think this is the cause of the problem.
This page is a Frankenstein of libraries; It includes GMaps API, Bootstrap.JS, Backbone.JS, Angular, Require.JS, IE polyfils, and a ton of proprietary stuff. I've tried in vain to figure out the source of this problem, and it would be good to know anything the codebase could be doing which would trigger this behaviour in IE.
Does anyone know of other factors which could cause IE to replace an <a> tag's innerHTML with the href value?
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 created a mobile site in html and jquery, but it is not loading properly in Chrome (or on an iphone). There is no backend to the site - all changes to content would happen right through editing the html. Inside of my html, I made no specific reference to ajax. And, each page links through "#pageid. The problem is that as I navigate the site, various pages do not display correctly unless I hit "refresh." URL is mobile.shorelinelake.com. I am VERY new to this, so please be patient with a newbie :) Thanks for any help!
http://mobile.shorelinelake.com (if you click through to "Lake" and then "Sailing," or "Cafe" to "Menu," you can see the problem - the page jumps after loading, cuts off the header, places content below the footer, or will entirely hide jquery elements...)
One thing I noticed right away is that your using an old version of Jquery and Jquery Mobile. There have been alot of improvements since the alpha that you are using. Also you are linking to a few files that aren't there. Phonegap.js and ajax-loader.gif for some reason are not found. In my console I see 196 warnings that I believe are all related to you using old versions.
Also you have 31 html errors. One example is here
line 88:
<a href="tel:16509657474" div data-role="button" data-theme="c" class="ui-btn-text">
You have alot of stranded </p> tags. Most of them are in the menu page. Fixing these errors is necessary to troubleshoot your problem. Try running your document through an html5 validator to find these mistakes.
I also recommend breaking this into smaller pieces. Here is my reasoning:
Easier to maintain and edit.
Keep the dom size reasonable. Jquery will remove the old pages from the dom keeping it very manageable.
Faster page loading resulting in a better user experience. Your user will probably not be going to each page. Only load what they need to see.
Bandwidth could be costing your user extra money on a mobile device.
I have a site that I put:
<body onload="ajaxLoad()" >
I have a Javascript function that then inserts data from my database into the text editor by using the setContent Javascript method of the textarea. It seems fine in Firefox and IE but in Chrome sometimes nothing shows up. There is no error, just a blank editor.
In the body section I have:
<textarea id="elm1" name="elm1" rows="40" cols="60" style="width: 100%">
</textarea>
In the head section I have:
function ajaxLoad() {
var ed = tinyMCE.get('elm1');
ed.setProgressState(1); // Show progress
window.setTimeout(function() {
ed.setProgressState(0); // Hide progress
ed.setContent('<p style="text-align: center;"><strong><br /><span style="font-size: small;">General Manager's Corner</span></strong></p><p style="text-align: center;">August 2009</p><p>It’s been 15<sup>th</sup> and so have a Steak Night (Saturday, 15<sup>th</sup>) and a shore Dinner planned (Saturday, 22<sup>nd</sup>) this month. urday, September 5<sup>th</sup>. e a can’t missed evening, shas extended it one additional week. The last clinic will be the week of August 11<sup>th</sup>. </p><p> Alt (Tuesday through Thursday) </p><p> I wouClub.</p><p> </p><p> </p><p> </p><p> <strong></strong></p>');
}, 1);
}
I am not sure if its some of the formatting that Chrome is rejecting but it seems like if TinyMCE can parse it in one browser, it should be able to do it in any browser, so I am confused.
Any suggestions?
Background:
For various reasons onload() is not considered the proper approach for loading Javascript, see for example Launching Code on Document Ready, with the most important/noticeable one being that Javascript code isn't run until the page has finished downloading entirely, including images and the like, which might take an eternity therefore (e.g. if an external banner ad server is down etc.).
Instead it is recommended to load Javascript as soon as the DOM is ready, but unfortunately there is no cross browser compatible native solution for this, see Getting notified when the page DOM has loaded (but before window.onload); please note that my entire answer is based upon the most excellent Javascript library jQuery, which offers a cross browser solution for this problem, consequently I'd definitely favor the two higher voted answers over the accepted solution myself.
Likely cause:
Your issue seems to be caused by the opposite behavior though: Chrome facilitates the WebKit rendering engine, just like Safari, and for the latter onload() is discussed to behave differently, see section When does onload fire? in Is Safari faster?. Another description of this problem specific to Chrome can be found in window.onload not working correctly in Chrome, without an explanation though.
In conclusion I suspect onload() to fire before the DOM is actually loaded completely, at least concerning the requirements of TinyMCE, which is notoriously fragile regarding issues like this and simply ceases to load.
Possible solution:
Just facilitating attribute defer on the script tag as outlined in window.onload not working correctly in Chrome is again not cross browser compatible, hence I'd simply go with the widely deployed and proven approach of using the already mentioned jQuery cross browser solution for the onload() problem, which is good practice anyway and should in principle take care of your inverse issue as well.
Update:
There are indeed some bugs filed against WebKit which could back my conclusion (no matter whether this behavior actually constitutes a bug or is intentional), see:
onload sometimes fired before all resources are loaded
window.onload fires before all subresources loaded
Window.onload is firing before image resources are loaded
I had a similar problem (editor not showing in chrome) and read in some forum, that if tinyMCE is unable to locate some files, it just stops loading. Try tracking down if everything is found using firebug's net tab (clear your cache first).
First of all; see to it that you have the latest version of TinyMCE.
I could not reproduce your problem given the information you provides. It seems just fine ( with the faked ajaxload ).
You could always try to go the "back entrance" in;
var myed = document.getElementById('elm1_ifr');
myed.contentDocument.getElementById('tinymce').innerHTML="<p style=\"text-align: center;\"><strong>hacking <span style=\"font-size: small;\">my</span> way in.</strong></p>";
Hope you good luck!
SOLUTION:
Ive been struggling with the TinyMCE toolbar not appearing in all kinds of secnarios....it would work in one user's IE browser, but not another. It would not work in Firefox or Chrome, etc.
Turns out if in the newest 3.3 version there are STILL bugs they have not fixed. This one occurs when in your webpage JavaScript code, where you instantiate the TinyMCE, if you added code for the plugin part where you load up two specific plugins, the toolbar fails to appear and you see HTML:
plugins:
"safari,spellchecker,pagebreak,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,
inlinepopups,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,
fullscreen,noneditable,visualchars,nonbreaking,xhtmlxtras,template,**imagemanager,filemanager**",
Remove all references to imagemanager and filemanager in your web page, then refresh your browser...
When you do, retest in Chrome and Firefox and IE and the TinyMCE suddenly appears! Wow....a miracle, huh?
Turns out their "main developer" hasn't fixed the issue but does explain it as such, if you want to try and still use those plugins and yet fix the problem. His quote is as follows:
"If the ImageManager/FileManager are old they might not use the new
scriptloader api. And the new 3.3 version will load all dependent
scripts async instead of sync. - Spocke - Main developer of TinyMCE"
There are a few ways to set content in a TinyMCE editor. If you want the content to be there when the page first loads, you can just put it between the tags.
Otherwise, you can do this through script in the following way:
window.onload = function() {
tinyMCE.getInstanceById("ProfileText").setContent('test');
};
I have wrapped the code in a window.onload block. If you have other functions that set content dynamically through this way after the TinyMCE editor has already loaded, then you do not need that.
There is an option oninit for the function tinyMCE.init(), put your method there:
tinyMCE.init({
oninit: function(){
tinyMCE.activeEditor.setContent('blah');
}
});
It works this way.
The editor is not fully loaded on document load event, as it the editor loader will post-load a bunch of files.
same problem here, ie needs
var ed = tinyMCE.get('content');
ed.setContent('zzz');
other browsers
document.getElementById("content").innerHTML="zzz";
i am quite disapointed
will need to check browser in javascript to get it working properly, thats suxx