This has got to be really boneheaded.. but after reading the same very simple answer over and over on various blogs and on the microsoft site, that AFAICT I AM doing it right, I am still stumped, so I ask here:
Why does the IE conditional in this test page render the literal <![endif]--> at the bottom of the page in IE, when viewed on a local network ? I am pretty sure that is the correct syntax for an IE 'Downlevel-hidden conditional comment'.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>IEconditionalSyntax_wtf.html</title>
</head>
<body>
well?<br>
<!--[if IE]>
wtf?!
<![endif]-->
</body>
</html>
Update:
to save your time reading all the comments... if you are having the same issue:
Most of the comments below basically just propose possible (but inconclusive, ineffective) explanations, and a couple guys report that they were unable to reproduce the issue. So far it seems no one knows the answer. I only see the issue when viewing the page on IE9/Win7 (w/any browser/document mode)... on my local server (page served by my local iMac 10.6.8, w/built in webserver).
But just because no one was able to rid my local server of this issue does not necessarily mean that the below suggestions will not answer the issue for you. Until we know the answer(s) I suppose it is not helpful to assume anything. So you probably do want to try everything listed below, if you also have <![endif]--> appearing on your page in IE, for seemingly no good reason.
Patrick gives a great workaround, but it does rely on jquery.
I debated whether to award the bounty (that I started, and which expired on 16 April 2012), or accept an answer, so that where acknowledgement was due it was awarded... and there was no clear action for me.. so I just decided to let the system auto-award half the bounty to Patrick for the great (albeit jquery) workaround. I did not want to give the whole bounty because the whole point of the bounty was to satisfy my curiosity as to why I am seeing the conditional comment in the first place. I also did not want to accept any answer (so far) because in this case I am not going to use any workaround since the issue only appears on my local network and so is irrelevant for the production code live to the world.
IE10 won't support conditional comments, so I suggest using a different method altogether.
Javascript works well for this.
Here is what I do that is A LOT easier to use, requires jquery
var userAgent, version;
if ($.browser.msie) {
version = "ie" + $.browser.version.substring(0, 1);
$("body").addClass("ie " + version);
} else if ($.browser.mozilla) {
$("body").addClass("mozilla");
if (navigator.userAgent.toLowerCase().indexOf('firefox') !== -1) {
userAgent = navigator.userAgent.toLowerCase();
userAgent = userAgent.substring(userAgent.indexOf('firefox/') + 8);
userAgent = userAgent.substring(userAgent.indexOf('firefox/'), userAgent.indexOf('.'));
version = "ff" + userAgent;
$("body").addClass(version);
}
} else if ($.browser.opera) {
$("body").addClass("opera");
} else if ($.browser.webkit) {
$("body").addClass("webkit");
}
Then you can write css like this:
span.something { width: 30px; }
.ie7 span.something {width: 25px;}
And, even better, use this in conjunction with modernizr and you can write rules based on feature support as well.. Note that those are global js variables, so you can even use those for different functionality based on browser. Like, if you need to write an ie7 hack or something.
EDIT: replaced code with less verbose version, same result
I'm dealing with a similar issue at work atm.
I would recommend testing it again with auto-detection of intranet off:
Plus all compatibility mode settings set to off
Plus with the addition of meta tag IE=edge
I think it may resolve the issue - IE is a strange beast!
It's because IE defaults to compatibility view when on a local network:
Many sites found on corporate intranets (read: the local network, like
http://myPortalSite) are Internet Explorer 7 capable today and expect
“IE” to act like IE7. In order to preserve compatibility with these
line-of-business websites and applications, IE8 defaults to
Compatibility View when displaying content in the ‘local intranet’
zone. An exception to this is ‘Localhost’ and the loopback address
(e.g. 127.0.0.1 + IPv6 equivalent). These addresses display in IE8
Standards Mode by default in order to meet the needs of web developers
and designers who often test pages meant for Internet consumption
(where IE8 Standards is the default) on local web servers.
Users can override the ‘local intranet’ setting by un-checking
‘Display intranet sites in Compatibility View’ at Tools ->
Compatibility View Settings.
http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx
To clarify, you are seeing this because you are accessing the site using 192.168.x.x, whereas I'm willing to bet everyone else who isn't seeing this issue is using 127.0.0.1/localhost.
I've added <!--<![endif]--> instead of <![endif]--> and it disappears.
I was having a similar problem where the conditional statement was in my <head> and <![endif]--> was showing at the top of the page when I displayed it in any IE browser, even when I uploaded the code to the server.
Since it was the last line before </head> I decided to move my print css call (which I needed to do anyway) to be the last line before the </head> and "voila!" now the <![endif]--> no longer displays in IE -- even on my local server.
HTML
<span class ="clean"><!--[if lt IE]></span>
<span class="clean"><![endif]--></span>
CSS
.clean { display: none; }
the conditional comments are rendered by internet explorer alone,the internet explorer 9 and above should support most of the elements in css.the comments will work fine with all versions of IE(best to use with 5 and 6).
I had recently this same issue.
In my case the conflicting code was one of the elements that I had inside the conditional statement for IE that had the lowest z-index in the page.
After setting this in order so that it would not be the lowest z-indexed it was fixed.
Related
I have been reading up about document type emulating and compatibility mode in IE and have to say its quite a bit to get one's head around.
I have developed an App with Bootstrap 3 and Ember rendering a few pages controlled through a menu.
I tested this in all browsers, Webkit, Moz, and IE and all seemed perfect. I work in a large corporate, so when I decided to test it on some of my colleagues' computers, on IE, I got a blank page. Now I found that very strange because they were all running IE10 or IE11, although there is the odd IE9. I couldnt understand it because it renders perfectly on my IE.
So anyway, I started hitting F12 on their browsers and realised that many of them had IE7 emulating even though they were running IE10 or 11.
I read a bit about this issue, and I found the following:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
So I proceeded to add this line to my page so it is as follow:
<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9" />
Now my question is this: Am I correct in assuming that if there was some sort of group policy set when using IE at work, that this workaround would solve the issue?
I will do some testing tomorrow morning, but just wanted to know if that is along the right lines?
Many people at work use Chrome and Firefox or whatever they want to, but there are obviously quite a few that use IE.
Take note that there must be a reason why the current group policy is set to enable compatibility mode (some other intranet app maybe) and that other app might stop working (or render badly) if you disabled it. If the admin have configured it in a way where that there's a Compatibility View list then you're in luck because all you need to do is not include your web app's URL into that list.
https://msdn.microsoft.com/en-us/library/ie/gg622935(v=vs.85).aspx
As for the document mode, I suggest for you to use this instead:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Setting the version to 'IE=edge' tells Internet Explorer to use the
latest engine to render the page and execute JavaScript.
https://www.modern.ie/en-us/performance/how-to-use-x-ua-compatible
The only reason you want to "IE=EmulateIE9" is that your app is targeting the legacy document mode which in your case it isn't since you're using the latest web frameworks out there. I assume you want the best UI experience for your users.
I understand that in your case the IE versions vary and that some might not support "IE=edge". It will be just OK because it will fallback to the highest supported document mode. For example, IE8 with IE=9, IE=Edge, or IE=EmulateIE9 results in IE8 mode.
https://msdn.microsoft.com/en-us/library/ff405771(v=vs.85).aspx
IE uses different security zones for different types of content. Stuff from the Internet is loaded in the Internet zone. Stuff from the local network is loaded in the Intranet zone. If you go through Internet Options, you can see that there are different security settings applied to the various zones.
If you're deploying the app through the network, then your app is likely loading the app in the Intranet zone (right click the page and then choose Properties to confirm).
By default, IE loads intranet pages in compatibility view, which is the same as using EmulateIE7 as the content value for the x-ua-compatible element. This means that, absent additional tagging/changes, your app is being treated as if it were being viewed in IE7.
If you need a specific document mode, you should be able to specify that mode directly in the content value, e.g, content="ie=9". If that doesn't help, then try adding an MotW to the page, so that the page is loaded in the Internet zone. In turn, this should allow the x-ua-compatible setting to take effect.
You can also change the Compatibility View Settings, provided they're not disabled through GPO, so that Intranet pages aren't automatically loaded in compatibility view.
Hope this helps...
-- Lance
The scenario is that the website works wonderfully on all machines except the ones where the client works. It's in Africa and I've no hope of getting access to it. He has limited IT knowledge and we don't know a great deal about the companies net policies.
I know that he is using IE8 with the doc mode being 8 as well, I suspected it was running in 7 because of some CSS issues but apparently not.
I use a JSON file and Ajax query to populate an important part of the site. It works well in all main browsers. I've used Dev mode and tried IE7 and IE8 and it still works.
However, his machine doesn't load anything, I output messages into the console and when he checked (confirmed via screen dump) there was emptiness.
What is love is either a way or means of debugging it from here, full details about his machine or some explanation as to why the json can't be read.
If anyone is using IE8 perhaps you could have a peek- it's kingpetroleum.co.uk/conversion.php
The drop down should populate the form web selected.
Thanks for any help.
Edit: there's a redirect on the index page that goes to the old site. Please use the /conversion.php if you check it out
As mentioned in the comments you need to add a polyfill for the JSON object which is not supported on older browsers. See here for more info on browser compatibility of the JSON object. They mention that it should be compatible for IE8, but this is not always the case and if the user is running IE8 in compatibility-mode it won't work either.
You should include the polyfill script file before you load your other scripts, I recommend doing it in conditional comments:
<head>
<!--[if lte IE 8]>
<script src="/path/to/json3.js"></script>
<![endif]-->
</head>
This would only load the polyfill for IE8 and below.
I have just installed IE9 beta and on a specific site I created (HTML5) IE9 jumps to compatibility mode unless I manually tell it not to. I have tried removing several parts of the website but no change. Including removing all CSS includes. On some other website of me it goes just fine.
Also, don't set it manually because then IE9 remembers the user setting and you can't turn it back to automatic (or at least I haven't found how, not even via private browsing and emptying cache)
Anyway. The site where it jumps to compatibility mode: http://alliancesatwar.com/guide/
One where it renders correct: http://geuze.name/basement/ (I can't post more than 1 hyperlink)
Both use the same doctype and all. Those sites have a lot in common(apart from appearance) using the same basic template(encoding, meta tags, doctype and the same javascript)
It would be great if someone has an answer for me! An HTML5 website that renders in IE7-mode is pretty... lame.
Works in IE9 documentMode for me.
Without a X-UA-Compatible header/meta to set an explicit documentMode, you'll get a mode based on:
whether the user has clicked the ‘compatibility view’ button in that domain before;
perhaps also whether this has happened automatically due to some other content on the site causing IE8/9's renderer to crash and fall back to the old renderer;
whether the user has opted to put all sites in compatibility view by default;
whether IE thinks the site is on your intranet and so defaults to compatibility view;
whether the site in question is in Microsoft's own list of websites that require compatibility view.
You can change these settings from ‘Tools -> Compatibility view settings’ from the IE menu. Of course that menu is now sneakily hidden, so you won't see it until you press Alt.
As a site author, if you're confident that your site complies to standards (renders well in other browsers, and uses feature-sniffing to decide what browser workarounds to use), I suggest using:
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
or the HTTP header:
X-UA-Compatible: IE=Edge
to get the latest renderer whatever IE version is in use.
I put
<meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
first thing after
<head>
(I read it somewhere, I can't recall)
I could not believe it did work!!
To force IE to render in IE9 standards mode you should use
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Some conditions may cause IE9 to jump down into the compatibility modes. By default this can occur on intranet sites.
I've posted this comment on a seperate StackOverflow thread, but thought it was worth repeating here:
For our in-house ASP.Net app, adding the "X-UA-Compatible" tag on the web page, in the web.config or in the code-behind made absolutely no difference.
The only thing that worked for us was to manually turn off this setting in IE8:
(Sigh.)
This problem only seems to happen with IE8 & IE9 on intranet sites. External websites will work fine and use the correct version of IE8/9, but for internal websites, IE9 suddenly decides it's actually IE7, and doesn't have any HTML 5 support.
No, I don't quite understand this logic either.
My reluctant solution has been to test whether the browser has HTML 5 support (by creating a canvas, and testing if it's valid), and displaying this message to the user if it's not valid:
It's not particularly user-friendly, but getting the user to turn off this annoying setting
seems to be the only way to let them run in-house HTML 5 web apps properly.
Or get the users to use Chrome. ;-)
The site at http://www.HTML-5.com/index.html does have the X-UA-Compatible meta tag but still goes into Compatibility View as indicated by the "torn page" icon in the address bar. How do you get the menu option to force IE 9 (Final Version 9.0.8112.16421) to render a page in Standards Mode? I tried right clicking that torn page icon as well as the "Alt" key trick to display the additional menu options mentioned by Rene Geuze, but those didn't work.
As an aside on more modern websites, if you are using conditional statements on your html tag as per boilerplate, this will for some reason cause ie9 to default to compatibility mode. The fix here is to move your conditional statements off the html tag and add them to the body tag, in other words out of the head section. That way you can still use those classes in your style sheet to target older browsers.
Looks fine to me:
You're sure you didn't on the settings globally or something? This is a clean installation of the beta on Windows 7. The developer tools report that the page is defaulting to IE9 Standard Mode.
I recently had to resolve this issue and here's what I did :
First of all, this solution is around tuning Apache server.
Second main think is that there's a bug in the IE9 which means that the meta tag will not work, instead of this solution try this
find/open your httpd.conf
uncomment/or add the following line
LoadModule headers_module modules/mod_headers.so
add the following lines
<IfModule headers_module>
Header set X-UA-Compatible: IE=EmulateIE8
</IfModule>
save/restart your Apache server,
browse to your page with IE9, use tools like wireshark or fiddler or use IE developer tools to check the header is there
I am aware that there are probably other questions regarding this topic. I guess that every web developer goes through this with IE.
My problem:
I am developing a web-based application fully based on Javascript. I am a Mac user. I was really happy that everything worked great in Safari, Firefox and Opera. I then asked a friend with Windows to check it with Internet Explorer, and things don't work as well. My application is very sensitive to the HTML standards.
The main problem is the CSS layout. The JavaScript itself seems to be working properly thanks to jQuery for portability.
My question:
How do you deal with Internet Explorer? Should I create a new CSS that is only loaded on Internet Explorer? Should I create a new version of the application only for Internet Explorer? How do you normally handle this? The application is pretty big both in feature design and in layout design.
Edit:
Using the CSS reset as suggested by Nosredna, already removed almost half of the problems. I guess it really is a good practice. I noticed that SO also uses it.
Do you specify a valid doctype? You can get Internet Explorer to be a bit more compliant by switching it into standards mode. http://msdn.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic2
Do you use a browser reset CSS file? That can help bring the versions together. http://meyerweb.com/eric/tools/css/reset/
Be aware of IE's CSS bugs: http://www.positioniseverything.net/explorer.html
For the skeleton of your layout, consider using markup that is known to work, such as http://matthewjamestaylor.com/blog/perfect-multi-column-liquid-layouts or http://960.gs/ for liquid or fixed layouts, respectively.
Keep up with JavaScript differences between browsers. jQuery handles some of them, but not all of them. http://www.impressivewebs.com/7-javascript-differences-between-firefox-ie/
Yeah, IE is a pain. If you want it to work in IE, you really want to test in IE every couple days. You don't want to save the pain for the end--you want to handle the nightmares one at a time.
By the way, if you think IE is a pain, try looking at your page with a mobile phone. The other day I went to REI.com with an iPhone and the middle fifth or more of the screen was taken up by a bunch of garbled markup that rendered as text.
Conditional comments.
<!--[if IE 6]>
<link rel="stylesheet" href="ie6.css">
<![endif]-->
<!--[if IE 7]>
<link rel="stylesheet" href="ie7.css">
<![endif]-->
<!--[if IE 8]>
<link rel="stylesheet" href="ie8.css">
<![endif]-->
<!--[if !IE]-->
<link rel="stylesheet" href="normal.css">
<!--[endif]-->
In the IE files, you can use #import to import normal.css, and then override the styles as necessary.
First and foremost, I don't wait until the project is done to consider browser compatibility.
Most of the time for CSS issues there are ways to do things that don't require browser-specific stylesheets to be loaded, so I try to use those solutions wherever possible. For example - if most of your issues are related to box model problems, things like using nested divs in place of padding can help to make sure everything looks correct without the need for separate stylesheets and templates for different browsers.
Browser reset to start. Level the playing field as much as possible and do away with browser defaults. Build your CSS from the ground up. (See: http://meyerweb.com/eric/thoughts/2007/04/12/reset-styles/)
Test early and often across all major browsers during development.
Try to accomplish as much as possible without browser specific hacks. Sometimes you'll need to work in some browser-specific CSS but it should validate (use the W3C Validation tool). Sometimes though there's just nothing for it but a conditional (and maybe even some JavaScript), e.g. fix for transparent PNGs in IE6 (See: http://nettuts.com/videos/screencasts/5-easy-ways-to-tackle-ie6s-transparency-issues/).
If you cannot run IE on one of your development machines, try http://browsershots.org. At least you can get some feedback this way.
Use a debug.css that highlights or outlines divs and other elements. Toss this into your HTML head if needed during development. This can be a huge help.
Use "developer toolbars" where available (IE, Firefox).
EXPECT THAT IE IS GOING TO BE A PAIN, and TEST IN 6, 7 and 8.
Have fun!
Here is how I try to reduce the pain of dealing with IE:
Use a reset.css - Yahoo! YUI Reset or Eric Meyer's Reset CSS
Be careful with floats, clears - they typically cause a lot of cursing.
Be aware of hasLayout bugs in IE, typically adding a zoom: 1 or height attributes helps fix this. Read On Having Layout.
Get the layout working in Firefox, Safari, Chrome, etc while keeping IE about 80% of the way there.
Implement a IE6.css style and an IE7.css style if needed using conditional comments.
Beer, Liquor or other adult beverages.
First, read On Having Layout, which explains how the IE rendering engine works internally. IE's rendering engine is from before CSS. It doesn't properly distinguish between inline and block elements like you'd expect. Instead, in IE an element hasLayout. Or not. This is the source of 99% of IE CSS bugs. So, read that article a couple of times.
As for fixes, I usually use conditional comments. Several reasons:
They are future proof, as opposed to CSS hacks. What if IE9 fixes the hack but not the bug you're using it to solve?
It's valid (X)HTML (conditional comments are just plain comments to everyone else)
It doesn't require javascript. You'd be amazed how many people have javascript turned off.
One remark about conditional comments: Never use an open ended match. That is, never do something like:
<!--[if IE]> <load css> <![endif]-->
<!--[if gte IE 7]> <load css> <![endif]-->
The reason is the same as hacks: make it future proof. What if the next version of IE fixes the bug and you don't need the fixes anymore? Or worse, the "fix" now actually messes up your layout in the new IE version? It's usually best to assume that the next version of IE has fixed the bug that you are working around. I have written a little bit about that back when IE 8 was on the horizon.
I think it would be okay to write a specific css file for IE. I know it is a pain, but because of some possitioning issues, IE6 looks different than all other browswers.
Use this line for your newly created css file:
<!--[if ie6]><link rel="stylesheet" type="text/css" media="screen" href="ie6_style.css" /><![endif]-->
With IE getting around 65% of the traffic, I don't think you can think of it as an after-thought.
Overall, I try to do as much as I can without making a separate CSS file for IE. I'll use come conditional formatting to target it specifically if needed. Overall though, at most you might need to do an IE only stylesheet to get it to work.
Just be sure that you are testing with the proper versions of IE for your audience, as IE 6, 7, and 8 are quite sommon.
As a last resort, when tweaking the CSS just won't fix things, I like to use Rafael Lima's CSS selector script. While it depends on JavaScript (most sites I build do anyway), it provides a convenient way to tweak CSS for different browsers and versions without separate stylesheets.
You can have :
.someClass {
margin-left:1px
}
.ie6.someclass {
margin-left:2px
}
<script>
if (internetExplorer) {
window.location = "http://getfirefox.com";
}
</script>
Keep the markup as simple as possible. Make small changes. Test every change.
I delete it
I would think that developing a new CSS File for use in IE would be considerably easier then re-writing your application, but I don't know what scale and scope your application has that would even render doing that a considerable option. I guess it can depend on what versions of IE you're looking to support.
We're at a point now that most users should have completely migrated away from IE6. IE7 is still a hassle, but nowhere near as bad as 6 was. With my projects, the default setup I sell is IE7 compatibility with code to direct users of IE6 and below to upgrade. If a client wants me to incorporate IE6 compatibility into a site, I typically increase the quoted price by 50% because of how awful of a headache is is to support the browser and how much extra visual code has to be written to make it work.
I know that this may fall into the 'too little, too late' category. That said, I would investing in VMWare or Parallels and create a Windows VM w/ IE6.
As you are developing, you should incrementally check your progress in the browsers that you care about.
That said, with an existing application, I would first make sure that my HTML was valid (there are a variety of validation services at your disposal) then, depending on the layout, I was section-by-section try to get the layout right, using comments to 'hide' the sections that you are not actively working on.
I usually do everything I can to avoid having to create a separate CSS file. There are a lot of CSS & HTML tricks & tips out there that should allow you to make it work in IE6 & up, as well as every other common browser. It just takes time to figure it all out. Unfortunately, sometimes with complicated layouts it can take a lot of time especially when you don't test it as you go.
I let others solve the problems for me. I use Yahoo's excellent CSS files included in their YUI library. They have one file to remove existing formatting for existing labels (e.g. H1 in IE does not look like H1 in Firefox), they have another to give me a default set of formatting that does look the same across browsers, they have yet another to standardize font sizes, and most important of all of them is their grid file. It gives me the ability to build hierarchical formatting of regions and sub-regions on the page very quickly and easily and I know it will work on any major modern browser (Yahoo tests the heck out of it to make sure it does).
It may not be the perfect solution, but it has been more than sufficient for my needs.
I had the same issue in my dev: IE6, FFetc + LAMP + custom MVC, based on Rasmus Lerdorf's article way back when he suggested noMVC-kind of like handle it using includes for headers, footers and the sort. I coded CSS, got stuck with FF not rendering it nicely. I had to go revise my CSS knowledge - I found that a single CSS implementation can render correctly in std. compliant mode(FF) and IE6. I liked that. I was happy with handling any changes using a single CSS file. My advice:
I know you have a Mac, go garage sale-ing (newspapers will tell you where they are), get an old PC for $10 (so far I've found plenty). This'll give you an opportunity to test out IE6 early, while you're at it get a KVM switch as well to access the machine when you need to.
One of the things I've gotten addicted to is IE6's setting - Disable all ActiveX scripts - makes browsing the web without ads a blast, anyways - test out your app with & without activeX settings, and see how well your site does. This has literally saved me hours of 'painful' moments folks above me have mentioned prior.
You prolly know how to test out FF/Opera/Safari with&without scripting
Finally - regardless of how heavy Javascripting your site uses, make sure without scripting the core features (which I'm sure you have lot's of) load properly.
I'm no expert, but sure hope my comments help you out a bit.
Cheery-O
I make sure my websites work natively and perfectly in ie9 , and work in ie8(possibly with features missing).
I prompt everyone that uses an older version to get chrome frame.
I never waste my time for ie7 and older, because using a 6 year old browser is pathetic, and should not be encouraged.
As nosredna said, use a valid doctype (see http://www.alistapart.com/articles/doctype/)
Then check your web site in the w3c validator (http://validator.w3.org/). If it shows no errors (or just a few), then IE should render it correctly.
I wouldn't put much effort in making it compatible with IE6, and just accept the fact that a website can look different in various browsers.
When IE8 is released, will the following code work to add a conditional stylesheet?
<!--[if IE 8]>
<link rel="stylesheet" type="text/css" href="ie-8.0.css" />
<![endif]-->
I've read conflicting reports as to whether this works with the beta. I'm hoping someone can share their experience. Thanks.
One thing to note:
It does work, BUT if you are loading the page/site local network (e.g. Intranet) it will load in IE7 mode by default! (update - localhost[*] is a special case, that does render in standards mode)
This goes against MSFT's original statement of going STANDARDS by default.
e.g.
http://127.0.0.1/mysite/mypage.php <-- IE8 by default (updated!)
http://localhost/mysite/mypage.php <-- IE8 by default (updated!)
http://machinename/mysite/mypage.php <-- IE7 by default
http://192.168.100.x/mysite/mypage.php <-- IE7 by default
http://google.com/ <-- IE8 by default
[*] - Scott Dickens [MSFT] noted in a comment here on the IE Blog that localhost was a special scenario in the Intranet (often used to develop Internet sites) thus would render in Standards mode by default.
To test what mode a page in IE8 is really rendering in, you can use check the developer tools or use this bookmarklet code (only works in IE8):
javascript:
var vMode=document.documentMode;
var rMode='IE5 Quirks Mode';
if(vMode==8){
rMode='IE8 Standards Mode';
} else if(vMode==7){
rMode='IE7 Strict Mode';
}
alert('Rendering in: '+rMode);
It worked for me – both in quirks mode and in standards compliance mode. However, it does not work when switching to IE8 compatibility mode.
Tools/Compatability view settings
uncheck them all
Thank you for your help. I've discovered the solution, apparently the problem was having each style sheet use its own title attribute. Once I took the title off all but the main style sheet, no prob.
This is a weird issue unique to IE8 - and although I've been told its supposed to work that way, something to do with "Stylesheet Preference" - it only serves to create problems since the solution requires you remove the title which could be helpful when scripting, etc - when you need to call the style sheet.
In any case, not sure if this is a bug, or its supposed to be that way, but I hope Microsoft investigates further.
Thanks
Why even bother writing a separate stylesheet for IE8?
If you've already debugged for IE7, you can force IE8 into compatibility mode, and thus display your code as though IE8 were IE7.
All you gotta do is put this RIGHT BELOW the opening head tag. Anywhere else and it won't work.
And then that's a half hour or so less work on average per project, no intense debugging for IE8 needed!
Even Msn.com does this - kind of ironic, eh?
Wrote a blog post about it recently: http://blog.sankhomallik.com/2009/11/16/stop-wasting-time-debugging-on-ie8-when-you-dont-have-to-or-get-ie8-to-behave-like-ie7/
IE8 renders pretty nice compared to IE7, I have stylesheets for IE6, IE7 and IE8; at first i thought conditional comments were not working for IE8 after a bit of experimentation i found some rules were not beeing applied by IE8 just because i needed to put the ancestor or parent class first, e.g.
i had a class like
.niceclass {some:properties;more:properties;}
it worked only if i changed it for something like:
.parentclass .niceclass {some:properties;more:properties;} or
#parentselector .niceclass {some:properties;more:properties;}
btw in my IE8-only css i have only one overriding rule, the rest is rendered almost like firefox, though thats not making me leave FF anyway!.
For my part I wanted to use rounded borders using css. IE8 on Vista does not support such. And since the graphics were so that the rounded borders would show a nice rounded shadow as well, the page looked terrible in IE8.
I tried using conditional comments, but to no avail, IE8 would not evaluate the if IE expression and thus would not include the external stylesheet.
Then I had a look at putting it into quirks / compatiblity mode, however, this still did not work as the CSS hacks I had used did no longer work for the IE8.
Last but least I found a working CSS hack that will render the page correctly when in compatibility mode.
* + html #test[id] { color:lime }
Now, I do not know if this works for IE7 or below, so you would have at least three
different hacks for each IE release you want to support, e.e.
* + html #test,
html+body #test,
* html body #test
{ color:lime }
I wonder what the next regression of the Internet Exploiter will behold for us.