What are cons of force a web site viewed in IE to compatible mode? Say we force IE9 to IE8 compatiblity mode?
Performance drawbacks
Can't use any new IE9 specific features like HTML5/CSS3/SVG
Why?
We run legacy web app which is developed since 2000 so it's a mess ball fighting to be compatible with Chrome, Opera, Firefox, IE6/7/8 and now we decide to add IE9 to the list. But with IE9 we run in issues with printing, "Permission deniend" JavaScript errors (probably something about cross-frame JavaScript calls) and next issues - the easy workaround is to force IE9 to behave as a IE8 and then everything works fine. But I am still not sure if it's way to go...
first our app is public site (for our clients)
You have a public website developed in 2000 and it doesn't work on modern browsers? Deprecate it or re-write it.
Don't hack your code to support modern browsers, the website is clearly poorly written and doesn't apply to standards. You can't get away with this.
The only place where you can get away with this level of incompatibility is intranet applications and even then you should simply state "it works on browser X, live with it"
You can't say that to public facing clients. I mean you can try, but have fun losing business to your competitors.
Re-develop your website to match the W3C HTML/CSS standards and the ES5 standards and it will be completely future facing (for some years).
Alas, the way the web works is that anything more then 5 years old is deprecated. So either re-write it every 5 years or get out of the web business.
In terms of actually using compatibility mode, don't. IE6-8 are horrible engines and should be avoided like the plague. If you use them then you can't write future facing standards compliant code.
Your code needs to match the standards and you should fix / shim / patch any browser specific bugs where those browsers don't implement the standards.
You cannot say you have tested in IE6/7/8/9 until you have tested in those different versions. Emulating the test environment is not the same as using the test environment. To my knowledge IE7/8 compatibility modes are the older render engines, not the underlying browser as a whole, bugs and all. It is closed source so you will never know.
Convert Microsoft's free to download virtual disk images for cross-browser testing to Virtualbox images and put them on a machine that just runs Virtualbox. An old machine will do, run the VMs headless and access them with remote desktop. In that way you will be able to test in all browsers without burdening your machine with MS/Spyware.
I believe your system admins can set IE to compatibility mode for all intranet traffic using the Group Policy Editor. Any site you create will from this point forward, you can add a meta tag to force IE9 to render natively and use all the newer features...
I'm having to do that on my current project using the following doctype and meta tag in my header:
<!DOCTYPE HTML >
<meta http-equiv="X-UA-Compatible" content="IE=100" />
Compatability mode is something that MS introduced to give people some chance to upgrade their applications, not for long term use. AFAIU.
If you want your application to be compatible with IE9, then you will have to change it. If you are trying to maintain IE6-9 compatibility then you have a real challenge, and you should consider whether this is really practical - in essence, you need at least 2 distinct sets of html. Is this practical for you?
IE9 compatibility mode is different form IE9 and IE8 - it draws bits from both. So you need to do a full test agaisnt the compatibility mode version, and ensure that it remains working against this.
So in answer to the question, the cons are that you are not being IE9 compatible, and there is a danger that when IE10 comes out, your code will not run against that in any mode. You are putting the effort into compatibilty testing without providing for future changes. You would do better, in the longer term, to make your code IE9 compatible. Also, the message you are giving your clients is that your code base is not going to be compatible for much longer. Unless you are talking to them about a re-work, this is a real negative.
However, it sounds like your entire code needs a re-work, to forget about IE6 and be written for modern working browsers. Using compatibility mode until that happens is probably OK. If you do this - and tell your clients - then staying in compatibility mode is viable.
Using compatibility mode will NOT cause the browser to use the JavaScript engine that was present in the old version of IE.
By that I mean it will run any JavaScript code using the IE9 engine. Which was a problem for us when debugging an old product that had a problem with IE7/8.
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.
It was possible to sign with digital certificate in IE and Netscape
http://bozhobg.wordpress.com/2009/04/16/how-to-create-a-digital-signing-solution-with-only-javascript/
What's the equivalent in IE 9 ?
You're going to have a problem with this.
The clue is in the code in the link you provided. Specifically, where it uses new ActiveXObject().
ActiveX is a very old technology and it has severe security issues. For this reason, it's use has been discouraged for some time (this was the case a long time before the article you linked to was written).
IE9 does still support it, but only for legacy reasons; its use is strongly discouraged, and you will need to go to the browser config and disable some security settings in order to get it working.
If you do get activeX working in IE9, you'll also need to make sure you have the relevant activeX controls installed on your PC that actually do the work (I've not used the ones in question, so I can't advise on them). In addition, since the activeX technology is deprecated, you may find that the activeX control you need to use may not have been kept up-to-date. This may affect whether it works with newer versions of IE or Windows.
I have an app that I have fully tested in Safari 5, IE 9, FF6, and Chrome 14. I'm not looking to block or exclude any browsers from the experience. But I want to warn/inform users that there may be a better experience in another browser, and if they choose to continue, there may be features not working or broken.
I have looked at jQuery browser detection, but it seems to be a bit quirky. I know the best solution would be to warn based on feature detection, but we are currently in beta and I am not completely sure what features make or break. Such as web workers, its known that web workers not working breaks our app, but it works in IE lower versions. But then there is an issue with Opera that web workers is available, but not functioning correctly.
Ultimately I am looking for an easy way to say Browser X Version y and up don't show warning, and those and under show warning.
What is the best way to approach this?
Browser detection is indeed "a bit quirky", in pretty much any scenario. The jQuery route is probably as good as you're going to get, but as you say it's not great.
A better solution is generally to do feature detection, especially in cases like the one you describe where your site relies on specific features.
The best feature detection library is Modernizr. This will give you an bunch of Javascript flags which are set to true or false according to whether the browser supports a given feature. It detects support for a whole bunch of stuff, including Web Workers.
Check out this: http://www.w3schools.com/js/js_browser.asp
-Easy way of detecting the user's browser with javascript. From there I'd just use a switch statement or something to display the messages for browsers that aren't tested yet. If you want the exact browser version you'll have to parse it from the "navigator.userAgent" field.
If the goal is full validation, you need to be even more specific about versions. Keep in mind that some browser upgrades are not 100% backwards compatible with previous versions. (Look at how IE8 mode in IE9 is not the same as native IE8 rendering, for instance.) You're going to have to retest with every new browser version, and sooner or later there's going to be a "Fully tested with browser version X, not tested with version X+1 that was released yesterday" problem. Feature detection, graceful degradation, and a warning non-intrusively displayed to the user if their experience is being significantly downgraded is a better way to go.
To directly answer your question, if you must implement what you are asking for just parse the user agent. This could be useful specifically watching out for a browser you know doesn't work right and warning, or as a bandaid for a badly written intranet app that is very picky about the exact browser version it will run on. For a newly developed app where you have control over the requirements, I would not recommend warning on browser version since there are better ways to do it.
I am getting a very weird kind of error with IE9. When I use a DOMParser from within a jsp page on localhost, it runs perfectly fine and gives the proper result.
But Shockingly, when I use DOMParser inside a normal HTML file (Not on the server. From the file system), I get this annoying message of "DOMParser is undefined" .. What is this and how can I make it work? Thank You.
P.S. It works fine on FF and Chrome
I would say that this is almost certain to be the browser running in compatibility mode when browsing local URLs.
You can check this by opening the dev tools (press F12) and looking in the top right corner; if it says it's in IE7 mode, then you've found the problem. Switch it back to normal IE9 mode and it should come right.
IE7 didn't support the DomParser object, so if IE9 is in IE7 compatibility mode, it's natural that it will stop supporting it too.
Ok, so that's what it's doing. But why is it doing this? There is a config setting in IE (both IE8 and IE9) which specifies that the browser should fall into compatibility mode when browsing sites on the local intranet. The reason for this setting existing is to allow companies who have internal sites designed for older versions of IE to upgrade to a new version without breaking those sites. It's intended to make like easier for corporate types who would rather not spend money fixing something when the broken version is good enough.
But it's a pain in the rear for the rest of us.
Obviously, if your site is on the public internet, it won't be affected by this flag, except when you're trying to work on it from localhost on your own PC. Therefore, the solution for you is to simply turn off this config setting in the browser and forget about it.
Of course, the fact remains that users of IE7 will still have this problem with your site, as their browser doesn't support the feature you're using. You could just drop support for IE7, and tell those users to upgrade. But if you want to support IE7 users, I believe that Dean Edwards' IE7.js script allows the browser to emulate this feature (along with a bunch of other stuff that Microsoft forgot).
Hope that helps.
I received this error, "DOMParser is undefined", on IE9 and it turned out to be an add-on that was disabled.
Name XML DOM Document
Publisher Microsoft Corporation
Status Enabled
Tools – Manage Add-ons – Microsoft Corporation
I'm not a 100% sure if I should be posting this here but where else can I post it (definitely not Server Fault or Super User) so hopefully it's not too inappropriate.
I am currently developing a script that I hope to release as a plugin for wordpress and other open source content management systems. The script's purpose is to allow web designers to attach stylesheets and javascripts dynamically according to which browser the visitor is using. So if their site looks a little odd in Chrome for example, then they can attach a css or javascript hack just for that one browser. There will be some more features to the script as well but that is the main purpose.
Anyway, I would like to know which browsers to include support for, for that I need to know which one's gives designers/developers the most trouble. Not just the name but also the version (i.e. Internet Explorer 4). Many thanks in advance!
IE6 is by far the most problematic of all browsers. Though it's use is declining month by month, it's still widely used. All IE browsers always suffered from display issues. Sometimes margins are not what they were set to, because you need to go down the css hierarchy to set all margins for it to understand what's going on. You shouldn't need to worry about anything below IE6.
There are many articles on the Net discussing this topic.
Here's an example
All versions of IE...Microsoft never likes to conform to W3C standards so they prefer adding hacks to "conform"
I know Opera browsers don't support CSS3 yet (latest release)....Have fun!
My vote as far as problematic browsers still in prevalent use would have to be IE 6.
Whenever anyone speaks of "browser compatibility issues", in almost all cases, the real problems are with IE. Markup written to web standards generally work well in any other browser save an occasional adjustment, but there are tens if not hundreds of web sites dedicated to hacking and fixing IE while there are none dedicated to doing the same. In fact, there are already javascript libraries for this very thing, getting IE to perform like other more modern browsers, such as Dean Edwards ie7.js and 'maximize' (I think it's called).
Most developers write to standards, test in the modern browsers, adjust if necessary, then, with a shaky hand open IE. Separate CSS and javascript for modern browsers is not necessary. While some may prefer to do so with IE, most of us make do with conditional comments and feed IE what IE needs to right itself.
Most people are designing for IE6+ these days, meaning that they are designing for W3C standards with IE6 bringing up the rear guard. Here's a fantastic site that breaks down all the features browser by browser, from IE6 on up.