Is there anyway to detect old browsers in HTML like the code I use for IE e.g :
<!--[if lt IE 9]>
...
<![endif]-->
I want to show a warning message as some of my web features are not supported for them.Is it better to use a JavaScript to detect this instead ?
Thanks
I finally used the code found at
http://www.php.net/manual/en/function.get-browser.php#92310
by using PHP
Feature detection. Not browser detection.
If you want to warn them about missing web features, why not use feature detection for those specific features, rather than browser version detection?
This has two major advantages:
Firstly, for your code, it has the advantage of making it clear what you're actually doing, and why you're doing it. This will make your code easier to work with in the future.
Secondly, this will allow you to reliably pick up all browsers that don't have the feature(s) you need, which means that if someone visits your site using (for example) and old mobile phone browser that's never been updated, you'll still be able to pick it up and show the correct message, even though you never thought to test for that specific browser.
You didn't tell use which specific features your site needs, so I can't give you details of how to detect it, but you may find the Modernizr library useful; it does feature detection for a wide range of modern browser features.
You may also have the option to add a 'polyfill' to your site to add support for the missing feature to old browsers. Modernizr is good for helping with this, and they also have a big list of polyfills you might like to try.
Related
I'm not sure I get the value of using Modernizr. I read, and reread their site. What is the value in having a script that performs tests to see if a browser has the ability to have the latest html5/css3 features? Does it actually PROVIDE the feature if the browser doesn't natively do it? Seems like a lot of work to do what jQuery can pretty much already do.
It does provide some features through polyfills
"The name “Modernizr” might throw you for a second, we’ll admit. The
library does allow you to use the new HTML5 sectioning elements in IE,
but aside from that, it doesn’t modernize any other features. The name
Modernizr actually stems from the goal of modernizing our development
practices (and ourselves)."
http://modernizr.com/docs/#polyfills
As I have been learning, I have developed a bad habit of only doing things in chrome. More recently I have started looking at stuff I make in other browsers; it sucks. I have noticed that the positioning in firefox is a little different, safari is basically the same, and IE is a hot mess. For now I am just going to focus on getting things to work correctly in firefox. Is there a sort of if Firefox conditional statement?
There is no equivalent to IE Conditional Comments in Mozilla based browsers like Firefox.
Depending on your server-side platform (if any), you could elect to sniff the browser type and conditionally include different style-sheets. Of course, you want to avoid this as much as possible. Usually by fixing things to work consistently across all browsers, you end up with better, more robust, site that will probably save you time in the long run.
Regarding CSS differences, you might consider starting with a reset CSS, such as the one suggested in Joe's answer, to provide a uniform baseline.
Regarding standardization of HTML and other features between the browsers, you might want to check out modernizer.
I find this script will solve a lot of quirks (minus IE of course) reset.css
In the interest of browser-compatibility checking, and given limited resources, is it worthwhile to test my HTML 4/CSS 2 web applications and sites with older versions of Firefox, or is it sufficient to test with the current version (v3.6 as at the time of writing)?
If I need to test against older versions, why? What are the things that I need to look out for?
UPDATE 1: This applies to a generally available audience and we can assume the browser usage patterns are the same as for the general public.
As a general rule, test your application in as many different environments as you can. It's never a BAD idea to test it against an older version of a browser.
Of course, given time limits and realistic requirements, you may want to limit the scope of your tests. For example, unless you're creating an application for the government, you usually won't need to test anything below Internet Explorer 6.
As for Firefox, the 2.x release was when it started to become really popular. It's easy to imagine that there are many people out there still on Firefox 2.x. The main thing you need to watch out for is differences with the way CSS is handled. Older browsers may render certain CSS tags differently or just plain don't have support for some of them.
I usually do check in older browsers, and follow this list http://developer.yahoo.com/yui/articles/gbs/ of A grade browsers. Unless it's just a very quick site I test in all A Grade Browsers.
The main reason to check different browsers is to make sure that the different users get the same experience and that your site actually works. Some obvious things are css fixes, javascript / ajax fixes, or things not working, PNG transparencies not working in IE6 and so on.
As said before, you need to know your demographics and what the site is used for. If it's an internal site, or one where only a limited people have access to it, and you know they don't use IE 7 or lower, or the older versions of Firefox, then there is really no need to cross check. But I'd say for the general public websites, stick with A grade browsers and you're pretty good.
If you want to test with a lot of different browsers, this free service might be helpful for you:
http://browsershots.org/
(Adobe had a commercial service in the past, but they shut it down in 2013.)
If a significant fraction of your intended audience use the old versions, yes.
Is this a generally available application, or will it be restricted to one organisation? If the latter, then the corporate policies on browser support will determine this.
First, find out what the browser demographics to your site are like.
That should drive any compatibility testing.
If you find that you have many users with older versions of Firefox, then it would be worthwhile.
You might find out that some other browser you had not considered should be a focus.
Good question!
If your application targets less tech-savvy people, I'd say a basic test against 2 is still mandatory. I've seen plenty of machines still running 2 because of turned off auto-updates and such.
My company makes its money off of a great user experience using IE6, 7, Firefox and Safari. 90% of our traffic ends up IE and probably 60% of that traffic is still IE6. IE6 has a bunch of known gotcha's such as accessing DOM objects while they are still being inserted crashing the browser. Almost none of these issues surface during routine testing, they almost always include some odd timing race condition that only affects our most important client of the week.
What process or tools do you use to ensure that known patterns that crash IE are not present in your code?
Added: For those suggesting sticking to 3rd party libraries: I agree that it will help a lot, but you still have to glue those APIs together with Javascript. Is there anyone that is not just crossing their fingers and waiting for someone out in the wild to let them know that there code has just crashed their system?
We don't worry about it. Instead, we use a third party tool like jQuery (well, EXACTLY like jQuery in our company) to ensure cross-platform idiosyncrasies are handled.
I recommend you rely on as many popular 3rd party frameworks as you can. They've undergone far more revisions and testing than you can ever perform. Obviously this means you should be using jQuery for all your JS related work.
Unfortunately there is no silver bullet for these browser bugs, as long as you go with JS & HTML you will continue to have these gotchas. At best you can compile a list of them, publish them on a blog, let the community discuss them and make sure all your devs learn them.
This is an example why Flash and SilverLight exist, which may seem like shocking suggestions considering you've spend an unmeasurable amount of time developing your UI, but if you want to be free of browser/OS bugs, going with a 1 company delivery package is the only way to break the 99.9% barrier for web bugs.
I do a try on window.event.srcElement (which'll only work in IE) and put the non-IE stuff inside the catch, and tie stuff up in my finally.
All other browsers seem to throw an exception with window.event.srcElement so I use that line first and if it gets passed that line it'll obviously be IE so I place my IE code there, if it ever goes to the catch it's clearly a browser that is a bit more standards compliant so I put the alternate code there.
This has saved my ass a lot when it comes to writing Javascript events dynamically using server side code that involves mouse events.
Hope that helped, gives you a way of supporting multiple browsers with different code without server-side detection.
Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.
Beleive it or not some of jQuery (and
other libraries) functions don't work
on all browsers.
Ofcourse, if you relate to IE5 or NN4, jQuery may not be the best pick. Otherwise, you won't have a problem with this.
I use jQuery for a HUGE site and i don't have problems with library. I have problems with plugins, but this is a different story.
And btw, i have less than 10 lines of pure js in my files. If you learn to use jquery efficiently, you won't need any js knowledge (sounds weird, but... this is my case :P )
Jeff mentioned the concept of 'Progressive Enhancement' when talking about using JQuery to write stackoverflow.
After a quick Google, I found a couple of high-level discussions about it.
Can anyone recommend a good place to start as a programmer.
Specifically, I have been writing web apps in PHP and would like to use YUI to improve the pages I am writing, but a lot of them seem very JavaScript based, with most of the donkey work being done using JavaScript. To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
Anyone have some good places to start using this idea, I don't really care about the language.
Ideally, I would like to see how you start creating the static HTML first, and then adding the YUI (or whatever Ajax framework) to it so that you get the benefits of a richer client?
As you've said
To me, that seems a bit overkill, since viewing the site without Javascript will probably break most of it.
This isn't progressive enhancement. Progressive enhancement is when the site works perfectly without JavaScript or CSS, and then adding (layering) these extra technologies/code to increase the usability and functionality of the website.
The best example I can give is the tag input box on this website. With JavaScript turned off, it would still work allowing you to enter tags separated with a space. With JavaScript turned on, you get a drop down with suggestions of previous entries.
This is progressive enhancement.
See also Unobtrusive JavaScript which is the bedrock progressive enhancement is built.
Going at it from the other direction is sometimes referred to as graceful degradation. This is usually needed when the site is built first with the enhanced functionality afforded by the various technologies then modified to degrade gracefully for browsers with those technologies are not available.
It is also graceful degradation when designing to work with older browsers (ancient in the Internets terminology) such as IE 5.5, Netscape, etc...
In my opinion it is much more work to gracefully degrade the application. Progressively enhancing it tends to be much more efficient; however, sometimes the need to take an existing app and make it accessible in these lacking environments arise.
Basically, if your site still works with JavaScript turned off, then anything you add with JavaScript can be considered progressive enhancement.
Some people may think that this is unnecessary, but plenty of people browse with addons like NoScript (or, with JavaScript simply turned off in their browser settings). In addition, many Mobile web browsers may or may not support JavaScript. So, it's always a good idea to test your site completely with and without JavaScript.
Progressive Enhancement is a development technique that stresses the primacy of the semantic HTML, then testing for browser-capability and conditionally "layering" on JavaScript and/or CSS enhancements for the browsers that can utilize those enhancements.
One of the keys is understanding that we're testing for what the browser can do, as opposed to browser-sniffing. Modernizr is a very popular browser-capability test suite.
Progressive-Enhancement is inherently (section 508) accessible; it provides for meeting the letter of the law and the spirit of the rule.
The Filament Group wrote the excellent "Designing With Progressive Enhancement" book on the subject. (I am not affiliated with Filament Group, though they are so freaking smart I wish I were.)
This is such an important concept and it saddens me that so few web developers understand it.
Basically, start by building a site/framework in Plain Old HTML -- structural elements, links and forms. Then add on some style and then shiny stuff (Ajax or what have you).
It's not very difficult. Like palehorse says, graceful degradation is more work.
Websites should work in any user agent, not look the same (not even look but sound if your vision impaired), just work.
Progressive Enhancement:
The plain HTML/CSS site is awesome (fully working and user-friendly).
Adding JavaScript defines a new level of awesome.