Is there any significant difference in behavior (HTML, CSS, Javascript, ...) with Internet Explorer 8 on different operating systems?
In other words, will a web page work the same way across IE8+XP, IE8+Vista and IE8+Win7, or are there some significant differences?
(I'm aware that installed plugins and fonts will have an impact, but that's a bit outside my scope at the moment; assuming compatibility mode X-UA-Compatible: IE=8 or edge)
Although The IEBlog contains very useful information, I haven't found this data there - so I'm assuming that there should not be any difference. However, search has turned up this (vague) question: "IE8 on XP: looks great! IE8 on Vista: looks terrible". Will have to check IE8+{XP,V,7} in VM in the meantime.
There are at least 6 versions of MSIE 8 and there are likely differences in layout due to bug fixes in the latter releases. A list of versions is available on Microsoft's support site:
http://support.microsoft.com/kb/969393
MSIE8 on Windows XP is version 8.00.6001.18702 and on Windows 7 is version 8.00.7600.16385.
There are some differences regarding css. When I used two divs, the first floated left and the second overflow:hidden; width:auto; IE8 on windows 7 rendered it correctly whereas IE8 on xp sp2 rendered the second div giving it incorrect width. Wierd!
I have had significant problems on IE8, working from a windows 7 machine I tested the site in IE8 using the standard mode the quirks mode and the IE7 standards mode and had no issues, however my client was using IE8 on an XP machine and told me that there were issues with the layout. I checked the site and it had displayed with significantly different styles.
So yes, there is a difference between IE8 on XP and IE8 on Windows 7.... though I have yet to find out how these differences are happening and how to solve them.
At least Wikipedia claims that Server Name Indication only works in Vista/Win7 versions of IE8. There might be other differences like this - after all, the system libraries IE uses might have differences between the different OS versions.
I also found an other rather stunning difference between IE8 on Vista(64) and IE8 on XP(sp3). The way the value attribute on the button tag is treated.
When you use <button value='10'>calculate 10%</button> the value submitted or extracted with javascript comes up with "calculate 10%" instead of 10 (the result on other major browsers) on older IE browsers (known issue) but also on IE8 on Vista. IE8 on XP on the other hand seems to comply to the standard behaviour the other browsers already embraced. Meaning it actually returns 10. Weird
There are bizarre behavioural differences in IE8 on XP also
for instance when tabbing between input controls in a table layout (think excel)
it wraps when the focus reaches the last visible control - instead of the last control in the row. Luckily I haven't found any serious problems - so customers can still work.
Absolutely different rendering is possible. My project has differents view in IE8+XP and IE8+Win7. In IE8+XP CSS rendering has significant differences with Windows 7.
Related
This is a very bizarre any very frustrating issue so please bear with me for the full explanation.
PREEMPTIVE NOTE: This is not a question of how to improve DOM/CSS for performance. You will see when you read the frustrations.
We have recently re-worked out website to be cross-browser (e.g. < !DOCTYPE html >)
After all the pain HTML and CSS re-factoring, we thought things were fine. However our website which has a pretty heavy DOM is incredibly sluggish to the point of being unusable. Example: clicking to select a row takes 10 seconds until it is highlighted and its check-box is checked.
Frustrations:
1) This sluggishness is not universal. Only IE9 suffers from this. IE8, IE10, FireFox, Chrome are all speedy!
2) IE9 itself if changed in debugger to IE8 documents mode becomes speedy! But not in its own IE9 mode.
3) While we are noticing the some sluggishness, the SUPER sluggishness (to the point of unusable) is only on specific machines.
4) Of course, one of those machines is a client.
The Question:
What could possibly unique about specific machines to cause super sluggishness? What could cause these machines to suffer more than others?
Things we've checked:
1) Windows 7 fully updated.
2) We do not have Windows update KB2976627 installed
3) We do not have Windows update KB2670838 installed
4) Disabled all Add-ons
5) Stress again that we disabled Shockwave Flash Object.
6) Tried disabling "Software Rendering" in Internet Options so that the GPU is used.
7) Reduced Windows display quality settings to run for maximum performance.
Additional Edvidence:
When the display area gets smaller, responsiveness increases. This happens when the browser window itself is made smaller or when dragged partly outside the screen boundaries. Also when performance improves as DOM elements removed/hidden.
DynaTrace shows a huge amount of time spent on rendering.
Webpage content:
There is ONLY: HTML, CSS2, JavaScript, JQuery, simple images.
JqGrid 4.5.2
JQuery 1.4.2
JQuery-UI 1.8.2
There is NONE of the following: Flash, video, CSS3, loaded third-party web content.
Machines tried:
OS: Windows 7 Enterprise N 64bit
RAM: 2 GB
CPU: 2.53 Ghz (2 processors)
OS: Windows 7 Enterprise 64bit
RAM: 8 GB
CPU: 2.67 Ghz (2 processors)
IE9 Version:
9.0.8112.16421 64-bit
IE9 Update Version: 9.0.31 (KB2977629)
We tried uninstalling update KB2977629 with no improvement.
Repeat of Question:
What could possibly unique about specific machines to cause super sluggishness? What could cause these machines to suffer more than others?
I discovered the explanation. As I feared when I phrased the original question JQGrid was a distraction (red herring). The real cause was answered in another stack overflow article.
In short, our page contains a lot of rounded corners (i.e. border-radius) styling. And there is a bug in IE9 that causes the rendering engine to choke on this. Once this styling was removed, everything was speedy again!
This also explains why IE8 browsers and even using IE9 with IE8 documents mode were fast. IE8 does not support border-radius so it didn't fall into this issue.
I have no idea which of the SE sites to ask this on (there's no windows SE site like there is on linux;) so I'll try this one.
I tried installing inconsolata to use as my default programming font. The problem is, it looks either messed up or is complete gibberish. I'm using windows 7 Home Premium if that helps.
I've included some screenshots so you can see for yourself. The first is of jsfiddle (which uses inconsolata) and the second is netbeans with the same code as the jsfiddle one:
Does anyone have any experience with this? Is there a fix for this problem?
I also just noticed that the font isn't even showing up on windows list of fonts
The only thing I can think to suggest is to increase the size of the font and see if it renders a little better that way.
I've used Inconsolata on both Windows 7 and 8 (RP), and it seems to work fine in my experience. I've also used it with my own software, without problems. I'm not entirely sure why this is happening for you.
So far our customers used IE6, so our system is compatible with IE6 only. Now, we want to support IE8 too. What differences are we going to experience while adapting our system to IE8? ( in the context of CSS and JS )
Thanks in advance.
See this, http://www.smashingmagazine.com/2009/10/14/css-differences-in-internet-explorer-6-7-and-8/.
http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx
If you have coded specifically against IE 6 (working around issues, using non-standard features), it may be a little rough, but IE 8 is infinitely better in terms of stability and standards support.
Along with moving to IE 8, consider supporting other reasonably compliant browsers such as Firefox, Opera, Safari, or Chrome. IE 8 isn't a bad product, but other browsers will "keep you honest" and help you avoid hacks and also expose you to features not supported by IE 8.
It's also worth noting that pretty much any framework you may already be using (if it's still being maintained) will have equal or better support for IE 8. Same goes for any third party components which render HTML/script.
Lastly, I would also spend some time with IE 9 to understand the direction that Microsoft is going with the product. Most IE 8 apps will work fine with IE 9, but there are some subtle differences (mostly fixing/reinterpreting style and layout implementations in IE 8).
Edit: Here's an excellent, free tool I use for running different versions of IE side by side:
http://www.my-debugbar.com/wiki/IETester/HomePage
Here are several things off the top of my head that are non-standard IE extensions. These will probably still work in IE 8, but keep in mind that Microsoft is making a big push towards standards compliance, and they aren't guaranteed to work in the future. Also, other browsers don't support them at all.
Proprietary filter syntax
CSS expressions (I really wish this WAS a standard)
DHTML behaviors (.htc files)
VBScript
Data islands (http://www.w3schools.com/Xml/xml_dont.asp)
HTML Apps (http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx)
Again, to my knowledge none of these things have been removed from IE 8 but they are all red flags for future maintainability.
Hopefully this question isn't as subjective as I think it may be.
I have an Intranet application which needs to work with IE8 as the enterprise is replacing IE6 as the standard browser.
Our testing team found that it did not work in IE8, little did they know that it actually did. Their browsers were set to run IE8 in compatibility mode for Intranet applications.
I found that if I set the meta tag for X-UA-Compatible to IE=EmulateIE8 that I could force the browser to render this application as IE8 and the application worked fine.
Are there any pitfalls that I don't know about for this solution? If so, is there a better solution?
Setting X-UA-Compatible to IE=EmulateIE8 will make the upcoming IE9 behave like IE8.
Initially, this may be what you want. If you're not in a position to fully test against IE9 when it comes out (sometime next year, I presume), it may help should the organization upgrade to IE9 immediately.
When you've fully tested everything, and want the application to work in IE9's native mode, you'll be a little bit stuck. You could set X-UA-Compatible to IE=IE9, and IE9 will work fine, but what does that mean to IE8?
That's all speculative though. Right now, it won't harm anything. If you need to make changes to handle later versions of IE9, you can do that later.
I'm putting together some virtual machines to test different browsers and I'm wondering if there is any compelling reason to be able to test the same version of IE on different versions of Windows. (i.e. IE8 on XP and Vista) I'm mostly talking about testing CSS to make sure it "looks right" across browsers, but if there were major differences in JavaScript I would want to know that too.
Are different versions of IE "generally the same" on different versions of Windows? Thanks!
The time and cost of testing different versions of windows would be better spent in other places. This would be one of the last things I would look at when looking for rendering issues.
I agree with both people who have answered previously, despite the fact that they disagree with one another.
In general, IE will act very largely the same across all versions of windows. However, there can be (and are) some occassional subtle differences. Whether these are important are not is up to you.
For the great majority of websites, I wouldn't bother with it. But for very precise web applications where you're using something like complex javascript, or if you require layout to be correct to the pixel for some reason, then it could be worth it. I'm thinking of cases where people are generating os-type applications in JavaScript where the DOM is really being pushed around, and where exact layout and flawless event-handling is critical.
Yes, I am currently testing something out and have varying results between XP and Vista.
--assuming you already have both platforms.
No, I would stick to testing on the current (IE8) and previous (IE7), unless it is a requirement to support older versions. These browsers should render the same across different versions of windows.
I personally dont bother with IE6, the sooner that is gone, the better
I would think there would be very limited cases where you'll notice a difference in IE between Windows versions. One example where you would is a Google toolbar bug I've seen in IE6 that renders html forms unusable. That bug seems to go away when you upgrade to IE8. But that problem is more Google Toolbar than IE.
Other differences you run into may be security or plug-in related. But in the default IE configurations I don't think you'll see any differences in rendering.