I have a corporate app with ie8 as the current forced browser. Machines are locked down tight and i can't even test on anything else because I can't install anything else. There are no other version of ie in use. it is 100% ie8. no 7, no 9. And they default to run in ie 7 compat / ie8 quirks mode.
In order to get stuff working right and to force standards mode, i had to use the html 5 DTD (to future-ready the site for mobile dev coming down the pipe instead of xhtml4) and
<meta http-equiv="X-UA-Compatible" content="IE=8">
heading in the template.
I have no information when they might go to ie9... or even skip to ie10.
Whats the best way to future proof this intranet site without being able to test it in ie9 or ie10, or a gecko browser?
I tried to follow tight standards and keep it clean with jquery and css and no in-line markup.
What does an ie9 do when it sees the ie=8 x-ua header? Should i use something else instead of this? I may not be working this app when the move comes. What notes should I leave for a future developer to be aware of?
Leave the X-UA-Compatible set to IE=8. IE9 and IE10 will try to switch to IE8 mode.
Related
Please forgive me if I placed this in the wrong section of Stack Exchange, I will be happy to repost elsewhere, Im just not sure which section to go to.
Why does IE8 display differently in Browser Mode (which is accessible through the IE10 F12 Developer Tools) than in XP Mode?
It seems that the CSS is rendered differently. Does anyone know the details as to why this occurs?
IE8 Browser Mode vs IE8 in XP Mode CSS renders differenty?
Yep, that's a pretty well-documented problem. It may be called compatibility mode, but the fact is, it isn't really all that compatible.
This is why it's generally considered a bad idea to use compatibility mode to do your testing.
Ultimately the only reliable way to test that a site works in IE8 is to actually load it in a real copy of IE8. XP Mode is a good way to do that.
I agree it's more of a hassle than switching the mode in IE10, but unfortunately, that's the way it is.
If I use the F12 Developer Tools to debug for IE, can I depend on the "Browser Mode" and "Doctype" to debug issues for IE8 and below?
By debugging I mostly mean for overall page behavior... HTML/CSS, A client says "The dropdown doesn't work in IE8", I have IE9... Instinct is to hit F12 and change the doctype or browser mode and test.
Short answer, no.
I would not recommend using compatibility mode. I have never quite understood why MS doesn't seem to do what Mozilla and Google do which is, disallow the use of deprecated tags. As an example, at my work, we have two tiers of browser usage, tier 1 and tier 2. Tier one consists of: Safari (oddly enough, we get quite a few customers buying via their iPads), Chrome, Firefox and IE9. Tier two is: IE8 and the rest of the pile. Recently, we had a bug where some checkboxes where not rendering correctly in **only IE8**; but worked fine in IE7 and IE9. The moral here is that using compatibility mode is testing under an assumption, and if you want thorough and correct testing, you cannot assume anything.
You can try to use the Quirks mode, but that's not 100% the same. If you are lucky, you will hit the same bug also in quirks mode.
The only sure way is to use a IE8. There are cross-browser testing tools that enable you to do so without any installs.
Just for bug reporduction purposes http://www.modern.ie/virtualization-tools offers some VM-s you can use.
I'm working on a corporate intranet and we have recently redesigned it using all sorts of CSS3 goodness as specified by a design agency. Our corporate standard browser is (still) IE8 so in order to make the CSS3 work I employed CSS3 PIE (http://css3pie.com/) which recreates the CSS functionality using VML via a .htc file - and it works great. However I've noticed that the http_referer value for pages viewed in IE8 is being returned as the location for pie.htc instead of the actual referring page and it was working just fine before the redesign. Firefox is tolerated as an alternative browser and for pages viewed in that browser all the http_referer values are as they should be. This is causing quite a headache for forms which redirect using this variable, as well as the logs which dump various environment variables to database for easy querying - and the guys who analyse the stats aren't remotely happy!
I have flagged this with the developer of CSS3 PIE and it's a mystery to him, but before I register a bug I wanted to see if it might be some failing of IIS or some setting I've missed in it (I'm using version 6 on Windows 2003). We have an Linux server with Apache as well for different purposes which I redesigned using the same technique and that doesn't seem to be displaying the same behaviour.
Does anyone have any related experience with PIE or any other .htc files on IIS which they were able to solve? Or is it some kind of IE8 bug that will never be fixed?
we experience the same issue. We removed it from the html. It could be an IE bug, I don't see any reason why the referer of the .htc should be the same as the page.
We have a lot of AJAX in our pages. Mostly it's been in our internal systems, so we haven't tested it with a lot of browsers. But at the moment we're developing a major feature, that will use AJAX, for our customers and we testing it more thoroughly. One of the tests have been in IE9 running IE7 mode, which worked just fine. But when we took a machine running a real IE7 browser, we discovered that AJAX only works once on any of our pages. It seems that after a part of the page is re-rendered with ajax, all javascript events in the part of the HTML that was re-rendered stops working. It's impossible to get even a javascript alert() box to appear.
Since we only have one machine with IE7, we would like to know if anyone can verify that this is a real problem, and not just a problem with this one machine of ours?
And if it is a real problem, what did you do to fix it? 10 % of our users still use IE7, so cutting that browser just isn't a workable solution.
UPDATE / SOLVED:
We decided to get a new server and set it up with Windows XP. Even though we don't support it, we tested it in IE6 and it worked. Then we installed IE7 and it worked too. Guess our old test server is all messed up some how. So all works in IE7 after all.
Thank you for the suggestions all.
Personally I intend to forget about older browsers, but I usually use the jQuery library for my AJAX requests since I usually use jQuery anyway for specific animations etc.
jQuery supports these browsers:
Firefox 3.6, 5.0.x, 6.0.x
Internet Explorer 6+
Safari 5.0.x Opera Current - 1
version Chrome Current - 1 version
source
Because jQuery AJAX is very much part of the jQuery library as anything else, I assume that the jQuery AJAX is supported by these browsers as well.
jQuery AJAX API
AJAX calls are cached in IE. Use "cache: false" in the ajax call options.
Hi i have made a website. And cause of some crazy reason i don't figure out the ie8 runs it with Browsermode: i8 and Documentmode: ie7 (standard). Why he doesn't use ie8 for both?
Did you put a valid DOCTYPE into your pages? Otherwise IE8 will run in compatibility mode.
See this blog post for details.