Firefox has a certain tolerance when rendering bad HTML. This means even if a closing tag is left out, the HTML will be displayed as if everything was fine. This tolerance aspect is particularly relevant when one is using JavaScript to manipulate or add content in the current page.
Since I use Firefox as my main testing/developing browser, I've been troubled more than once by this behavior of which the consequences are loss of functionality in "more strict" browsers. For instance the same code in Microsoft Internet Explorer failed to produce any visible output due to the mentioned missing tag on the added content.
Now the question is, is there any way of telling Firefox to be more strict about the accepted HTML and fail instead of "guessing a fix" for it (specially when the HTML is being added via JavaScript)?
PS: I've tried playing with the DOCTYPE but the results were the same.
Don't use browsers to check your HTML; they're very much not designed to do that. Use an actual validator, such as the W3C's validator. There appear to be lots of Firefox extensions which will validate the page with a click or automatically, though I'm not familiar with them since I don't use Firefox as my primary browser.
All parsers are forgiving to some degree. Most mainstream sites have errors (not that this makes it excusable, just saying). If you develop with a debugger attached, you will catch script errors much more quickly. I also catch script errors by using a minifier in my build process (which will fail on major syntax issues). I valid my HTML markup using Visual Studio 2010's real-time warnings (which aren't always perfect) and periodically use the w3 validator service.
For browser choice, I usually develop across the board; in one sitting I literally may switch between IE7/8/9 modes, Chrome, and Firefox. Safari and Opera usually work if the aforementioned browsers are covered. This way I don't get too far down an erroneous path.
BTW, DOCTYPE is important (even if it doesn't always seem that way).
I've found that it is best to just break down and do your primary work in IE.
If you use a good doctype ( < !DOCTYPE html > ) and set the x-ua-compatible header to IE8 mode, the extra work you have to do to make an app work/look good in other browsers is minimal.
Related
I am developing a web page primarily using Firefox. Often I encounter that my web page renders properly in Firefox but has some unexpected behavior in Chrome and IE.
Generally if its related to javascript, I usually open Developer Console in Chrome and see if there were any errors and that gives me a clue as to what might be wrong.
Unfortunately, I am generally lost if its a CSS related or HTML element issue.
In one particular case, I have placed a div inside a <td> and I am lost as to why the chrome cannot render it properly irrespective of the fact that firefox is happy and does not complain.
So my question is, how to debug issues related to rendering of HTML pages in Chrome and CSS and determine what might be offending.
My related question is, is there a guidelines to make my web page work in almost all the popular browsers with little effort? I am particularly thinking in terms of tool or process which will warn me of compatibility issues with my web page.
IE (Internet Explorer) and little effort doesn't match to each other, you have to invest more of your time and effort only for IE, illuminate IE and be happy, as a suggestion, use Twitter Bootstrap if possible, it's a ready and tested css framework (maybe framework is not perfect name).
Basically, as far as I know, only a css reset could be used to gain some consistency but still you have to test over different browsers because each has different rendering engine. If you want to keep IE in the list then test the layout for IE at first.
Only for the IE or Inconsistent Exposer (IMO) there is a developer tool available (IE Tester) to test layout (HTML/CSS) over different versions of IE and only works on Windows so it may help you a bit if you are Windows user. There is also an online tester available and sometimes helpful, it's browsershots.org.
Also IE has a debugger/developer tool and pressing F12 will bring it so you may see something like this:
Google Chrome has it's built in debugger/inspector (CTRL + SHIFT + I) and on Firefox you may use Firebug extension and these browsers are not dumb like IE and there are lots of debugging extensions available for these browsers for free, not worried about these good guys.
Generally speaking, IE users are dumb and used to see dumb things on their screen so I don't think too much about them because they really don't know the difference but as a developer you may need to think about it and in this case I would demand extra charge from my clients if they want me to make a site compatible for IE < 10 because it requires extra effort.
You dunno me ? Leh--hoo-zehar (Looser) IE am a legendhhh. Smooky...!
I am not aware of any tool that will warn you because there is no way for a tool to validate the result of what you desire.
As far as how to test HTML/CSS. Chrome supports the most HTML-5 and FF is a close second. If you develop in chrome it normally works in FF and via verse. IE is where the pain is. IE does not support all HTML tags and often will render things wonky. I normally create my webpage and focus on FF and chrome once I like the results I open IE and debug. 98% of the time it is CSS changes that need to be made. I debug CSS first and if I am not able to resolve it with CSS after a decent amount of work I will look into changing the HTML. I try to avoid changing HTML because you have to debug all other browsers again.
Styles and code developed in Chrome will generally work in Safari, Opera(same engine), and IE 10+ with few inconsistencies. You'll get a few rare positioning issues with some CSS3 specs in Firefox, specifically in background positioning. You'll also find some javascript issues unique to Firefox.
IE9 is generally a good sport and usually doesn't have too many issues. IE8 will have a few and they'll be significantly different based on the OS (as there are multiple versions of each IE and they all support different specs for Javascript and HTML) specifically you'll find lots of issues with XP IE8 and really shouldn't support it (Microsoft doesn't even want to).
For the most part you'll be developing to IE inconsistencies unless it's a CSS3 spec with the occasional javascript strangeness (which js frameworks generally can help with since a few of them were made with that goal in mind).
As far as tools, browserstack is nice but doesn't give you a lot of time. If what you're trying to use is modern caniuse is a good place to visit first. Almost all issues between non-IE browsers will be HTML5 or CSS3 specific though.
I have a strange problem with IE 10. Many jQuery scripts that are working fine on IE 8, 9, Chrome, firefox and safari but broken on IE 10. Issue came into light only when some users switch to IE 10.
Easiest solution I found to add
<meta http-equiv="X-UA-Compatible" content="IE=9" />
in <head></head>.
The problem is site has a lot of pages and most pages don't have inherited master page.
So is there any way to add this through javascript, as we have a common referenced js in all webpages.
No, there is no way to do that in Javascript. At least, not in a way that would actually achieve anything -- the rendering mode is fixed when the page is loaded, so there's nothing you can do to change it in JS from within the page.
An alternative solution would be to add the X-UA-Compatible flag as an HTTP header. This would set it on all pages across your site without requiring any HTML changes.
You've mentioned that you're using IIS. This page should help you configure it for your site.
However, the real solution would always be to fix the site so that it works in IE10. This is likely to be the best solution for you because IE10 is actually pretty good at being standards compliant; if you've got something that works in IE8 and IE9 but not IE10, then it's near certain that it is actually something wrong in your page rather than anything wrong in IE10.
This in turn means that even if it works today in other browsers, there is likely to be a bug in your code that could break in future versions of other browsers.
The other problem with using IE's compatiblity mode is that it really isn't an accurate copy of the old IE version it's supposed to be compatible with. This is particularly the case with IE10's compatibility modes, because there are some old features that have been removed from IE10 completely, and which are therefore not available in compatiblity mode either. This means that IE8 and IE9 might work, but IE10 in IE9-compat mode might not work. It depends what the actual issue is, but you'll need to test it just as thoroughly in compat mode as you would in real IE10 mode.
And then there's the question of how you deal with the site going forward into the future. What about IE11 and beyond? Compat mode removes new features that IE might have, so by sticking with IE9 mode you'll be stopping yourself from being able to use features like text shadow or CSS transitions. You'll want to use those features eventually, so you will need to fix the site at some point; why not now?
Thanks everyone for responses and help.
What I was looking for was like adding below code in web.config:
<httpProtocol>
<customHeaders>
<clear/>
<!--This setting will make document mode to highest mode available we need have mode 8 and above-->
<add name="X-UA-Compatible" value="IE=IE9"/>
</customHeaders>
</httpProtocol>
in <system.webServer> section.
JavaScript is run after the page load, this means you will not be able to modify the meta response from the server to the client afterwards. It might be easier to address the issues with IE 10 instead if there are no common headers
var m = document.createElement("meta");
m.setAttribute("http-equiv", "X-UA-Compatible");
m.setAttribute("content", "IE=9");
document.getElementsByTagName("head")[0].appendChild(m);
But as Teemu hinted, it will most likely not show any effect.
It is hard to figure out (from the question) that what is actually being broken? Can you tell which JavaScript code is being broken?
Anyways, one solution may be changing the document mode, what you have stated above. Another solution may be changing the browser's JavaScript version (if the problem is due to in-compatible JavaScript).
You can change the browser's JavaScript version be adding a browser configuration file to App_Browser folder in you asp.net application. Or to do it automatically, add this nu-get package and modify it.
install-package App_BrowsersUpdate
https://nuget.org/packages/App_BrowsersUpdate
This might not have anything to do with ExtJS, but I have to provide all information in order to get a proper answer :D.
I have an application that uses ExtJS 4.1 for displaying some grid panels.
When I run the application on localhost, everything looks as it should.
When I deploy the application on a remote server, the grids are no longer displayed as required in IE8: all the information is squeezed in the table, irrespective of the column alignment(the column headers are good, but the other cells are overlapping).
To make things more general:
The same application runs good on localhost(no matter on what computer), but when I deploy it on a server, IE8 doesn't display things as it should. This happens because of the CSS or JavaScript files(probably both related to ExtJS).
Why?
Per the OP's request to post this as an answer:
By default, IE runs with Compatibility View enabled for Intranet sites. The reasoning for this was probably that most intranet sites using IE were written specifically for IE, and thus would break when IE began adhering more closely to standards.
This potentially causes a difference between what is viewed locally versus on an intranet (and on the internet). This can be changed across the board with a Windows group policy; some organizations are receptive to this, some can't/won't make a change.
If declaring meta http-equiv="X-UA-Compatible" content="IE=edge" doesn't fix the behavior (as stated in the comments), I would start by checking that compatibility view actually is the problem.
Other Possibilities
I'm assuming that you have the correct doctype in place (e.g. HTML 5 or HTML 4 strict, though I believe others will work fine too). This works in conjunction with the "X-UA-Compatible" declaration.
Malformed markup can trigger Quirks Mode, which looks atrocious in almost any scenario. That's probably not the case, since it looks fine locally but it's easy to check. Make sure that your document is reasonably valid and--more importantly--that there are no leading characters before your DTD (which confuses the parser). Incorrect server code can cause data to be written to the response stream before the HTML, leading to this behavior.
Lastly, reduce the problem to its simplest form, i.e. find the most basic markup which causes the behavior. If this doesn't give you any insight, post the broken code in a JS Fiddle.
If it is IE8, check in developer tools document mode, it might be going to quirks mode.
I manage an e-commerce site running under SSL.
The problem is happening on the final page of my site's shopping cart that loads under SSL. The problem is that Internet Explorer 8.0 (including version 8.0.6001.18702 and other versions of IE8, but reportedly not all versions of IE8) complain about at least one non-secure element loading, which is scaring away some of my prospective customers. IE8 displays a dialogue box after the page has apparently fully loaded (with seemingly no missing images) that says:
"Security Warning: Do you want to view only the web page content that was
delivered securely? This webpage contains content that will not be delivered
using a secure HTTPS connection, which could compromise the security of the
entire web page. (YES/NO)"
I tried to track down all invalid images and links that may be loading via HTTP, but no to avail. Firebug Lite shows nothing non-secure. I'm starting to think this may be a bug within IE8 that was corrected in IE9, which does not complain.
TO REPRODUCE THIS ERROR: Click here using IE8 (or Chrome) to add an item to your shopping cart. On the resulting page, click on the GREEN button on the right that says, "Proceed to Secure Checkout." You will notice that you see the above "Security Warning" from IE8.
QUESTION: How can I determine what the browser is attempting to load non-securely, or how can I suppress the "Warning" message?
UPDATE: It seems the "Security Warning" is due to the suspended JavaScript execution on this page. But the same question still remains. How can the "Security Warning" message be suppressed or "debugged"?
Wireshark is usually pure overkill if its used to debug standard web browser based applications because it provides way to many information which are usually not required to exactly pinpoint the problem. A much better solution in this case would be to use Fiddler which is a simple yet a very powerful debugging proxy which is, aside from its many useful functionalities, also able to clearly distinguish between SSL and non-SSL traffic.
Its also able to simulate a "man in the middle" testing environment which effectively allows it to decipher SSL traffic. Of course the generated "on the fly" certificate is clearly marked as untrusted in all browsers to prevent misusing it.
EDIT: I followed the given instructions in order to provoke the problem yet I had no problems with any kind of security warnings in IE8. Also Fiddler is showing that all the resources are loaded through SSL.
I know this is an old post, but since there wasn't an answer posted that fixed my similar situation, I thought I'd shared what I found in case anyone else stumbles onto this page. If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
See this Microsoft KB Page, which says the glitch only occurs in IE6 and IE7, but it happened to me on IE8 on XP, too, and the same fix worked.
I ran into a similar problem in the past with IE8, and what it appeared to be was an issue with cached items. I wasn't able to completely pin it down because, like you, I checked every asset and found nothing that was not loading via SSL. However, I noticed that if I prevented all caching and forced IE to load all assets from the server, the warning disappeared.
I don't know if there's a bug where certain items pulled from cache don't get recognized as secure, but it seemed to have something to do with it.
Disabling caching is obviously a bad way to solve a problem that only impacts a subset of browsers, but it might be a tip that could lead you in the right direction.
Click checkout at the top of the page?
Not in https anymore is it?
If you have SSL-backed pages, then every assets (js, css, images) should be served by HTTPS protocol too. It's the same behaviour for 90% browsers
As Jon stated:
If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
While the Microsoft KB Page does provide the fix, the best solution is to implement it as follows (place in a script at the bottom of your page):
Ext.removeNode = Ext.isIE ? function(){
return function(n){
if(n && n.tagName != 'BODY'){
n.outerHTML = "";
}
}
}() : function(n){
if(n && n.parentNode && n.tagName != 'BODY'){
n.parentNode.removeChild(n);
}
}
firebug is quite useful tool that I can't think myself living without it. I also downloaded the js file that helps you get similar functionality when using IE6 hoping it would help me resolve some issues, however, the messages I receive are not quite friendly such as:
"Expected ':' (default2.aspx,16)" - on line 16 there is nothing that can possibly expect a ":"
or
"Object doesn't support this property or method (default2.aspx,198)" on line 198 nothing interesting that can require any support for anything.
my site looks like a different web site in IE6.. most of the css doesnt work, some of the jquery functions doesnt work and I need to get this site work in IE6. Any help would be appreciated in terms of;
how to know what the messages (like the ones above) mean in IE6 and how to effectively debug js in IE6?
where to start for css compatibility.. e.g. shall I create different css files for different browsers and load them by detecting the browser? or are there any common issues and hacks?
I am lost so please give me any direction to start..
You debug javascript in IE6 with:-
Microsoft Script Debugger
The QuirksMode website is useful site to determine which bits of CSS is implemented in what way by which browser. Note IE6 "standards" mode rendering is notoriously buggy.
You can try Companion JS. It is pretty good with respect to debugging. It requires Microsoft Script Debugger as well.
Companion JS thankfully supports "console.log" (via firebug). It is free tool. Debug-bar is a good CSS-DOM-Javascript debugger, but it is not free for commercial purposes.
The two tools I use are:
Web Development Helper
IE Developer Toolbar
They somewhat duplicate each other's functionality, but each one can be useful for different tasks. The Web Development Helper has a built in JavaScript console, it's not as good as Firebug but it's better than nothing and easier than the MS Script Debugger.
"Expected ':' (default2.aspx,16)" - on line 16 there is nothing that can possibly expect a ":"
The error won't be on line 16 of your .aspx file, probably not even on line 16 of the HTML source the aspx file produces. It'll be near line 16 of one of your linked .js files. Which one? IE won't tell you.
You could find out by adding extra lines at the start of each .js file and seeing what happens to the error line number, but it's probably better just to install Script Debugger already.
IE8 finally fixes this.
shall I create different css files for different browsers and load them by detecting the browser? or are there any common issues and hacks?
Start with standards-compliant CSS, and a Standards Mode doctype, and test in Firefox 3, or Opera, Safari, Chrome. Mostly they'll give you more or less the same results. Now test in IE7 and hopefully it'll just work.
The troublesome browser today is IE6. You may well need to add hacks for it. You can do this in a separate stylesheet if there's a lot of them, or just use the "* html" hack for the occasional rule.
All the older hacks, your Box Model Hacks and so on, you can forget about. They're only of use for IE5, which is dead, and IE6 Quirks Mode, which you shouldn't be using.
or have an AJAX call to send debug variables/messages to ASP (PHP) script that will log it. this will help if the problem is with variables undefined or having similar issues.
For what it's worth, I've found the line number errors are much more accurate when using a separate js file.
I still use IE6 as my primary browser when developing. It saves a lot of headaches later, since you will often find CSS issues much earlier in the process.
I also find it helpful to use a JavaScript logger to send debug messages. This being an alternative to a bunch of alert messages. Personally, I use the yahoo UI logger
I use one of two things for js debugging: Microsoft Script Editor or Firebug Lite. Go here for more info.
As for the CSS, I recommend a CSS Reset. And for the little differences in IE6, consider using conditional comments.
When making an an application to be used in multiple browsers, quirksmode is a lifesaver.
EDIT: blackbird is a nice cross-browser tool for tracking state.
I've used MS Script Debugger with some success, also IE Developer Toolbar and Firebug Lite. I recently learned about MS Visual Web Developer Express Edition, which has been a big improvement so far.