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.
Related
I was wondering why javascript os detection techniques like navigator.userAgent, navigator.appName, navigator.appVersion and navigator.platform are in process of being dropped from web standards.
https://developer.mozilla.org/en-US/docs/Web/API/Navigator
If you visit every of those navigator props, you can see
Deprecated
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.
So I would like to know
Why they're removing this
Will they introduce a new way for OS detection
Can I use these techniques even if they're deprecated.
Probably there is a lot of cases where we need to know OS version.
It was incorrectly or accidentally marked as deprecated on MDN. They quickly corrected the page once they saw the problem, but since it had been a definitive source, references to it being deprecated still exist here and there.
Here's the conversation where it was fixed:
https://groups.google.com/forum/#!topic/mozilla.dev.mdc/tIx2iiH2u3o
You can use:
navigator.userAgentData.platform
I think the general thinking is that it's becoming unnecessary. Theoretically at least, there shouldn't be any functionality that works differently in any browser vs any other browser--at least not for JavaScript.
What you usually browser sniff for are features, and there are plenty of ways to find most of that stuff out without having to infer anything from the nightmare that is userAgent.
So it may be deprecated, or it may not. But it's a good idea to not have to sniff the browser. That stuff can get real complicated real fast. Even if it does become deprecated though, it'll probably stick around for a few decades so that half the web that still relies on it doesn't crash and burn.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am working on my first project that requires me to worry about cross browser compatibility. Since this is my first time doing so, I dont know how to go about completing the project. I am specifically worried about IE. Should I complete my project in a more graceful browser then hack it to work in IE, or should I simultaneously build my program up in both environments?
Design your site to work in standards complaint browsers first. I always start with Firefox, even when developing on my company Intranet (where everyone uses IE). Doing so will let you focus on getting your markup and CSS correct. This is what is most important.
The important thing to note is that you'll want to "future proof" your site, and concentrating on a standards compliant browser will help you do that.
Then, once you're confident your site is looking correct (validators are your friend!), try it out in the versions of IE you want to support. In order to get your layout to look OK in IE, I strongly suggest using different stylesheets for each version of IE, using conditional comments.
Also, you should note that many others have been in the same scenario as yourself, and there is quite a bit of help available. One popular method of forcing IE to behave is the ie-7.js project.
Lastly, be mindful of the top IE bugs, such as:
IE6 Box Model Bug
IE6 transparent PNG images (I have used this fix in the past)
A few tips:
Code to Standards — Start by ensuring that what you've just developed works in Firefox and Chrome, and then verify it in IE. I'll usually then check it out in Safari. It's always better to make sure your markup/code works in a more standards compliant browser first.
Validate Early, Validate Often — You don't want your design to look perfect in one browser, find out that it's broken in another, discover that to fix the broken layout you needed to correct some invalid HTML/CSS, only to find that now the first browser looks wrong.
Progressive enhancement — will be your friend. Start basic, with simple HTML and simple CSS, and no JavaScript whatsoever. Repeat tips #1 and #2, then move on to more complex styles and layout. Contiue this iterative process until you are happy with the design in all browsers. Only then should you consider JavaScript to polish the site.
Check each browser often — Don't develop the entire website in a single, compliant browser like Firefox, and then decide to "see what's broken" in IE. If you've got a complex, dynamic website, there could be MANY problems in Internet Explorer. Trying to decipher each one when they are compounding on each other is a nightmare.
Reset Stylesheet — As #Eir mentioned in the comments, find a good reset stylesheet. Although, they have fallen out of favor for some people, I find putting every browser on the same footing from the start helps tremendously.
Use a Framework — I find CSS Frameworks to be excessive, but some people swear by them, so to each his own. On the other hand, as soon as you have made it to the JavaScript phase of development, I highly recommended using jQuery or MooTools. They are very focused on circumventing cross-browser inconsistencies.
Let JSLint hurt your feelings — Even when using a JavaScript framework, there are certain standards of coding to which JSLint will help you conform. Some of the options are a bit overly strict, but I promise that if you clean your scripts through this tool often enough during development, you will almost never encounter those strange times when everything seems to work in all browsers except IE.
And some great tools! Everything in the above list you should consider mandatory practice. The following can spice it up for you in a pinch, but is optional:
CSS Browser Selector — it is rare that you will need this, but if all else fails, it's way cooler than using a separate stylesheet just for one browser (I despise conditional comments). It basically adds classes to your <html> tag, so you can do things like the following in your main stylesheet: .ie7 #header {/*stylese here for IE7 only*/}. It supports a lot of browsers on many operating systems. And it's fast.
Browsershots — Nothing beats the real thing, but if you can't install a suite of browsers, this and other tools like it can help.
IE6 CSS Fixer — I outright refuse to debug my designs in IE6. I coerced my company (via many chagrin-filled meetings with IT and management) to drop support for it (thank god). It's just counter-productive to waste so much time forcing this pile-of-ahem... Anyway, if you aren't like me and need to support IE6, this tool can help.
Also you should focus on resetting css like this
OOoooo, good question:
here's my take:
Decide which browsers you are supporting. I suggest IE 7 + 8, FF, Chrome and Safari as in order of importance. (only support IE6 if you absolutely have to!). It helps if you know your userbase here.
Use a css reset. Different browsers have different default styles. a css reset gives you a consistent base.
Keep your markup as simple as possible. Follow Standards (and see progressive enhancement on Stephen's answer).
Test every step of the way on your target browsers. That way you can correct problems right away. http://crossbrowsertesting.com/ is the best resource for this, but there are free ones for screenshots as well.
Avoid Hacks as much as possible. Most cross-browser issues these days can be solved without resorting to hacks.
Ask questions here when you get stuck. If this is your first project dealing with browsers, you will get bewildered by inconsistencies. We all face these issues, and are glad to help.
Be ok with the fact that webpages are not going to look exactly the same in all browsers. (once again, see progressive enhancement).
Good luck coding!
I develop for Firefox first, and then work out the IE buggery. Rarely do I "hack" it, rather find something that works in both, or at worst use IE conditional comments. Just one coder's preference. Always a good idea to test with Safari, too.
Two big advantages of Firefox are: the Error Console, and the Firebug plugin.
there is alot of greate tools that makes life alot easier for you there is for example a
css framework called blueprint you could use, it has already everything set for every specific browser so that you get the same outcome in all browsers. And using jquery as your javascript framework does add an extra insurance that you'll have it working in most browser.
but remeber there is no such thing as 100% cross browser compatibility for all the browsers and all the versions in world.
In theory would be best to develop for all browsers at once, always testing for every browser...
Realistically, that rarely happens... I typically develop/test with firefox. when I introduce complex javascript or css, I check in ie... this tool is incredibly handy for checking all versions at once... google ie tester.
By checking all browsers at regular intervals, and when you make complex changes, you ensure that major features are compatable :)
Also, ensuring that all of your code is valid is not only good practice, but helps identify cross browser issues.. google w3schools validator :)
Using javascript libraries such as jquery also aid in cross browser compatability, and some even come with css libraries as well. These libraries are purpose built for quick, reliable features that are typically cross browser guaranteed.
Finally, before launching, use launchlist to check that all works: http://lite.launchlist.net/
Hope all that makes sense and helps with your first project :)
Post Sniffing Rules
Although browser sniffing used to be quite popular, it's now gone out of fashion (for good reasons) and has been deprecated (if not dropped) by popular libraries such as jquery.
The better way is to do feature detection.
Exception To The New Rule
However, there are times when you might be targeting (for whatever reason) a specific browser. iOS safari is a good example, as are other mobile browsers, as the mobile platform has different ui concerns.
My Particular Purpose
For my purposes, I want to target IE specifically in order to alert the user to use another browser.
You may not agree with what I want to do, but please disregard that in your answer.
With this in mind, what the best, most reliable way to detect browser versions, more specifically any IE version, and iOS Safari too.
Is it safe to still use jquery.browser?
Use Conditional Comments. The are a perfect fit for what you're after.
Also, it's all very well and good to tell people to use feature detection but in the real world, when you have 3 days to update the browser detection on your company's website you can't go and re-write all the Javascript just to take advantage of this, so I say, heck yes, use browser sniffing, because sometimes you don't have a choice.
I've recently seen some information about avoiding coding to specific browsers an instead using feature/bug detection. It seems that John Resig, the creator of jQuery is a big fan of feature/bug detection (he has an excellent talk that includes a discussion of this on YUI Theater). I'm curious if people are finding that this approach makes sense in practice? What if the bug no longer exists in the current version of the browser (It's an IE6 problem but not 7 or 8)?
Object detection's greatest strength is that you only use the objects and features that are available to you by the client's browser. In other words given the following code:
if (document.getFoo) {
// always put getFoo in here
} else {
// browsers who don't support getFoo go here
}
allows you to cleanly separate out the browsers without naming names. The reason this is cool is because as long as a browser supports getFoo you don't have to worry which one it is. This means that you may actually support browsers you have never heard of. If you target user agent strings find the browser then you only can support the browsers you know.
Also if a browser that previously did not support getFoo gets with the program and releases a new version that does, you don't have to change your code at all to allow the new browser to take advantage of the better code.
What if the bug no longer exists in the current version of the browser (It's an IE6 problem but not 7 or 8)?
That's the whole point of feature/bug detection. If the browser updates its features or fixes a bug, then the feature/bug detecting code is already up to date. If you're doing browser sniffing on the other hand, you have to change your code every time the capabilities of a browser changes.
Version and User Agent parsing remind me of stereotyping or racial profiling. Object detection is the way to go in my opinion. The book jQuery in Action does a good job of pointing out the fine details of why.
Well, if it is a problem in IE 6, but not IE 7 or IE 8 then the feature/bug detection mechanism will mark it as not a problem and use the appropriate functions.
It makes sense in practice, browser sniffing causes many issues, what if you don't update your signatures in time for some new browser that is released? You are now locking out potential customers, and visitors because you believe that their browser is unable to support something that indeed it can.
So yes, it makes sense, and your second question is moot because of the fact that it does the detection in the first place, if it is no longer a bug everything will work as expected without the work around that is in place if the bug was there!