There used to be a nice way to tell if a web browser is IE or not, by using this technique in HTML:
<!--[if IE]>
Non-IE browsers ignore this
<![endif]-->
or
<!--[if !IE]-->
IE ignores this
<!--[endif]-->
but this doesn't work anymore in IE 10.
Any idea what to use instead to tell IE from other web browsers (using HTML or JavaScript)?
PS. I need to be able to tell ANY version of IE from non-IE web browser.
I appreciate all your insight, but none of it answers my actual question. Again, I am not asking about the feature detection. All I need to know is if the web browser is IE or not. The following uses JavaScript and seems to work for all current versions of IE (including IE10):
<![if IE]>
<script type='text/javascript'>
if(/*#cc_on!#*/false)
var bIsIE = 1;
</script>
<![endif]>
and then to check if it's IE, do this from JavaScript:
if (typeof (bIsIE) != 'undefined')
{
//The web browser is IE
}
else
{
//The web browser is not IE
}
Obviously the code above assumes that the web browser has JavaScript enabled. But in my case the browser detection is relevant only if it has scripts enabled.
Every version of Internet Explorer is different from the others, just as every version of Chrome, Firefox, and Opera are different from their predecessors. You don't target vendors such as "Microsoft", "Google", or "Mozilla" when you develop websites—you target features.
Rather than asking "I'd like to use ::after, is this browser a Microsoft browser?" You should instead ask "Does this browser support pseudo-elements on the :: prefix?" This is feature-detection, and it's nearly always perfectly on target. Rather than guessing what a browser is capable of by its vendor, you determine what it's capable of by what it can actually do.
This may not be the answer you were looking for, but it's the correct answer nonetheless. If you're asking how to identify all Microsoft browsers, you are approaching the problem (or what you perceive to be a problem) incorrectly.
For proper solutions, I would encourage you to use tools like jQuery and Modernizr. These will handle API normalization, shimming of newer elements in older browsers, as well as feature-detection. This is the correct way to do things, and had developers been taking this approach from the beginning you may not have such a distaste for Internet Explorer today.
The link you give in your question - doesn't work anymore - which is to Windows Internet Explorer Engineering Team Blog leads to the following statement
Conditional Comments
<!--[if IE]>
This content is ignored in IE10 and other browsers.
In older versions of IE it renders as part of the page.
<![endif]-->
This means conditional comments can still be used, but will only
target older versions of IE. If you need to distinguish between more
recent browsers, use feature detection instead.
It seems to me that the IE team are strongly pushing for the use of feature detection rather than browser detection as the quote from the feature detection link above shows.
Same Markup: Core Guidelines
**DO**
Feature Detection
Test whether a browser supports a feature before using it.
Behavior Detection
Test for known issues before applying a workaround.
**DON'T**
Detect Specific Browsers
Also known as browser detection. Don't use the identity of a browser (e.g. navigator.userAgent) to alter page behavior.
Assume Unrelated Features
Don't perform feature detection for one feature, and then proceed to use a different feature.
So it appears that the Windows Internet Explorer Engineering Team are setting IE up so that you will not be able to use browser detection for IE10 and above.
EDIT
I do not use IE10 but does
navigator.appName=='Microsoft Internet Explorer';
work in IE10?
It isn't enough to just say IE10 is good enough and ignore the problem. It really depends on what you are trying to do. For most purposes feature detection would likely handle what you need. The far, far more complicated route is to start user agent detection by pulling in the user agent string from the HTTP request header. If you aren't careful with this you can go wrong pretty quickly.
To view your current user agent string in a browser JS console:
console.log(navigator.userAgent);
Here is a list of reported user agent strings across all kinds of browsers:
http://www.zytrax.com/tech/web/browser_ids.htm
Note that all MS Explorer agent strings will contain "MSIE," but first you have to weed out browsers like Opera that will also include the "MSIE" string in some cases.
This function returns true if the client browser is Internet Explorer, tested on versions 9-10-11.
function isIE(v) {
var ie;
ie = RegExp('msie' + (!isNaN(v)?('\\s'+v):''), 'i').test(navigator.userAgent);
if (!ie) { ie = !!navigator.userAgent.match(/Trident.*rv[ :]*11\./) }
return ie;
}
// Example
var ie = isIE();
var ie9 = isIE(9);
var ie10 = isIE(10);
NOTE: the function is incomplete and won't allow for isIE(11)
Related
Ok everyone, I have a requirement to only support IE 11+, Chrome 31+, etc. The specifics don't really matter at this point. I know it's not ideal to restrict other browsers, but this is a vendor requirement and isn't my call. I'm just trying to figure out how to go about doing this.
Initially I wanted to use feature detection (my assumption was that the site needed to be HTML5 compatible). These requirements have changed. Is feature detection still viable for this? I would prefer to not use user agent sniffing, since it's so easy to spoof.
I'm using ASP.NET, C#, .NET 4.0, jQuery, HTML5, CSS3
How can I accomplish this?
Thanks in advance!
You can look inside the Request server variable for useful information about the browser. While debugging, it looks to me like this is getting generated from the user agent. From what I know about the web though, this is how clients communicate to servers what they are capable of viewing.
There are a few properties that can help you within Request.Browser.
Request.Browser.Type //Returns "Chrome41"
Request.Browser.Browser // Returns "Chrome"
You could also use conditional comments for IE, something like this:
<!--[if IE 11]>
(Redirect users here or however you want to handle it)
<![endif]-->
I'm sure you've seen these before, but that statement basically is targeting any IE version less than 11. These are Microsoft / IE specific so while this will help you with your IE issue, you will most likely have to rely on the user agent or Request as above for other browsers.
So for those who worked on iOS web applications probably know that due to Apple's policy, Chrome and other mobile browsers on iOS use a very ancient javascript engine. This is why we need to disable some of the rendering for Chrome and other none-safari browsers for iOS.
I had been reading this question and there is no useful answer there. Here are some of my approaches (failed):
Use is_iOS = navigator.userAgent.match(/(iPad|iPhone|iPod)/g) to detect if the browser is on iOS. And then use:
is_FF = navigator.userAgent.match(/(firefox)/g) and is_Chrome = navigator.userAgent.match(/(chrome)/g)
to kill off those firefox and chrome browsers.
I then realized all the browsers share identical user agent string with iOS safari. So I imagine the method should be running a javascript function that only Safari can run and then determine if the browser is Safari.
So, there's two schools of thought when choosing which native functionality you should use while working in browsers. One school of thought is checking the userAgent as you are doing here and using/removing features based on the userAgent.
The problem with checking userAgent is that it gets complicated really fast. You have already run into an interesting problem, but what will happen when you find that ie8 does not have the feature you are looking for?
A better solution may be to check if the feature exists in its current context without worrying about userAgent. A great example would be the new HTML5 audio element. Based on browser support, we can tell that it does not exist in ie8 nor Safari < 4.0. Instead of checking if the browser matches the ones mentioned here you can just check if the feature exists. As we know that the audio element is an instance of the Audio class. We can simply check:
if (window.Audio) {
//load and play the HTML5 audio element here
}
That is much simpler than checking the userAgent.
Please not not turn this into a discussion about which browser is better and the ethics of forcing a browser. It's an intranet, and it's what I am required to do so everyone calm down =o)
I need to prevent employees from trying to bypass the check to not use their preferred browser instead of the company mandated one + version. The decision was made based on security, compatibility, costs, and the use of company made Firefox extensions.
I came across this Force users to use Chrome/FireFox instead of IE which I can do easily in PHP to force use of Firefox, however it relies on the useragent which can easily be changed in numerous browsers and with the use of plugins.
Is there a JavaScript solution that I can use that DOES NOT check the useragent or any value that can be 'easily' modified by a user/plugin? It would need to detect if the browser is Firefox and what version it is. Site uses jQuery so if it can be done using that, however not required then by all means yes. I just am not aware of what ways to detect a browser and it's version that there are without checking useragent.
I remember way back in the day for detecting Netscape or some browser checking for document.all was used instead of useragent, so I'm guessing something similar, which only Firefox will have.
Thank you very much in advance!
Try this: http://jsfiddle.net/DerekL/62exH/
Because Firefox handles onpopstate differently than other browsers, you can then use this to detect if it is Firefox or not. This can not be changed by user or script. But the disadvantage is you can only get the version number by doing navigator.appVersion.
You can only try but cannot succeed in forcing a browser. That being said you can strip down the CSS in other browsers which may completely make your site close to unusable in other browsers.
To make your CSS only work with Firefox you can try approaches given # Targeting only Firefox with CSS
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.
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.