If I'm developing something for the web and I've already done functional testing in Chrome, Firefox, and IE on Windows do I really need to do the same on OS X? Are the browsers (Chrome and Firefox) widely different in how they work between each operating system that separate tests are needed in each browser for each OS?
You should not need to. By and large there will be no difference between the two on the same browsers. You may rarely find quirks that differ slightly, but I've never come across any.
I posed this question on Reddit and Hacker News. Here's a brief roll-up of the highlights of responses:
There appears to be consensus that the main difference you're likely to experience has to do with font types rendering (types render more smoothly on OS X and iOS).
Many suggested that the majority of what you see between Windows and OS X versions of the browsers is the same, with only subtle differences in the user agent based on the OS design (e.g., native radio buttons, scrollbars, etc.). This is not exclusive to browsers but to all apps running on each OS. Also, feature support in browsers doesn't vary between OS, i.e., if it's only a partially-supported feature in Firefox, it's that way on all platforms.
There were suggestions that, given the strong preference for developing on the Mac platform, it makes more sense to test on OS X's versions of Chrome and Firefox (and Safari) and remotely test IE (e.g., modern.ie, BrowerStack, Sauce Labs, etc.) Using a cross-browser testing suite like BrowserStack doesn't preclude the possibility of including mobile browsers (for later discussion).
Sources: Reddit, Hacker News
Related
All:
I wonder if there is any plugin or something work as a virtual container can turn IE into Chrome environment? Just like running applet across browsers?
If no way to do this, can any one suggest some light weight solution to build an VM image?
Thanks
The Chrome team used to support a utility called Chrome Frame, but this was during a time when nearly all major IE versions had poor support for HTML5 and "CSS3".
The utility is no longer supported:
[In 2009] many people were using browsers that lagged behind the leading edge...
Today, most people are using modern browsers that support the majority
of the latest web technologies. Better yet, the usage of legacy
browsers is declining significantly and newer browsers stay up to date
automatically, which means the leading edge has become mainstream.
Given these factors we’ve decided to retire Chrome Frame, and will cease support and updates for the product in January 2014.
I'm not sure what you mean by the second part of your question though, regarding the building of a virtual machine. Virtual machines of Internet Explorer are available for free though http://modern.ie.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My team is working on a new site which should be cross browser compatible (IE 8+, Chrome, Safari, Firefox, Opera) and cross platform compatible (Desktop, Tablet, Smartphone).
We've been looking at a lot of the new methodologies for achieving this such as HTML 5, responsive design, using JS libraries that abstract a lot of the browser mess away from the user but since the browsers and even MVVM, but the one major issue that I've been facing is how fast the browsers are changing. With both Chrome and Firefox using a model of continuous delivery it becomes harder and harder to test. And from the looks of it other sites have the same problem (it seems like it's hit or miss these days as to whether a site will work in a particular browser)
What suggestions do you or your team have for testing new browsers as they come out?
What things do you do during development to decrease possibility of having code break when a browser update comes out?
And how do you decide when you will or will drop support for a browser version?
NOTE: I've altered the order of your questions to leave the longer answer at the end.
Your questions
What suggestions do you or your team have for testing new browsers as they come out?
Actually, as you said, Chrome and Firefox are continuosly delivering so it eases the process. The last version you have is mostly always the version the user has.
For any other browser (and Chrome and Firefox old versions) just select a version of each and act as a "high pass filter", testing any version up from the one you selected.
How do you decide when you will or will drop support for a browser version?
Take a look at the statistics of browser use. There are many resources such as statcounter, w3counter, w3cschools, or wikimedia. If possible, add an analytics tracker to your page and you will have data about what devices, platforms, browsers, and versions of them the visitors use to access the site.
What things do you do during development to decrease possibility of having code break when a browser update comes out?
The key is to use a well defined methodology, based on the existing standards. Continue reading for a personal recommendation.
Workflow to ease cross-browsing
Step 1: Bootstrapping
At first decide: Graceful degredation versus progressive enhancement. Both are valid techniques, but makes sense using the first to fix existing projects and the second for newly created projects.
Then select libraries to avoid typing existing code, focusing on the 3 languages: JavaScript, CSS, and HTML. HTML5 (+CSS3) is the better choice today but support for older browsers must be provided. The following libraries ease supporting them:
modernizr for feature detection and conditional loading of js or css.
jQuery for ajax and dom related tasks.
normalize.css for normalize default browser styles, rather than just "resetting" them.
Notice that all of the js libraries listed above allow custom builds, an important thing when performance matters.
Html5 Boilerplate provides a strong template from which start the layout. It includes modernizr, jQuery, and normalize.css. Its github repository is a good resource to learn a lot about cross-browsing techniques. This article on its wiki has a nice set of links to start learning.
Step 2: Do the work
Designs should be mobile-first and responsive. This article on html5rocks introduces well why and how.
While "doing the work":
Follow the w3c standards. Avoids using hacks, specially CSS hacks, when possible. Review often the HTML5 specification as it is pretty unstable.
Take care of ECMAScript 5 features when writing javascript. Rely on libraries to avoid code breaks caused by deficient browser implementations. Do not extend the DOM.
Automate tests when possible. Layout and specially layout polishing, including animations, are manually tested cause it's quicker but UI functionalities like form submision can be perfectly tested with automated tests.
Use tools to ease tasks. Chrome + devtools or Firefox + firebug are the very basic must-use, but there are a bunch of tools to ease cross-browsing tests, even automating those tests.
Annex: Tools and resources
Cross-browser testing
Browserstack is just awesome. Allows testing on all devices, platforms, browsers, and versions.
Browserling is an alternative to browserstack. It is developed and maintained by Peteris Krumins and James Halliday, both recognized members of the node.js community and well-known developers. They also published a tool to automate the process called testling-ci, but this is only relevant if using node.js on the back-end.
modern.ie provides tools to ease testing on internet explorer. Developed by Microsoft, the site provides live testing through browserstack and downloadable virtual machine images with pre installed software.
adaptability testing for "responsive design"
respon.si is an online tool meant to test the visually appearance of layouts. It allows selecting a resolution so it's useful for responsive layouts testing. Notice that any other tool to select a resolution can easily do the same.
What suggestions do you or your team have for testing new browsers as they come out?
As part of our definition of done we support the following desktop browsers:
IE8+
Firefox 3.6
Firefox (latest)
Chrome (latest)
Safari 6
The support of the latest versions of Firefox/Chrome is fine because they both provide automatic updates, and so if anybody has a problem on an older version of the browser, it's out of our hands and they should update.
The majority of Firefox/Chrome testing can be done on our machines, but there are obviously discrepancies with how the different OS' handle fonts, and some quirks with native form elements that may or may not carry over to versions on Windows.
To test Firefox versions on OS X I use the "Install all Firefoxes" script that I created, to allow me to run multiple versions of Firefox side-by-side.
Our development team uses Ubuntu and Mac OS as their environments, so we have a dedicated machine with virtual machines for each version of IE, and Chrome/Firefox on Windows, and Safari 6 on OS X.
These virtual machines were setup using the images provided by modern.ie. We're remotely accessing the machine with the virtual machines on so that we don't need to break our workflow and go to another machine.
What things do you do during development to decrease possibility of having code break when a browser update comes out?
The obvious things are avoiding CSS hacks, and making sure that the HTML/CSS/JavaScript that is written meets our code standards, and our definition of done.
If we're using experimental CSS features, we ensure that we're providing vendor prefixed and lastly w3 definitions of properties:
-moz-foo: bar;
-ms-foo: bar;
-o-foo: bar;
-webkit-foo: bar;
foo: bar;
Obviously this introduces some technical debt, but if you're using a preprocessor for your CSS, the overhead of this can be reduced.
We keep a separate stylesheet for IE and load it using conditional comments, so that we can fix problems in IE without affecting the integrity of the rest of the front-end for other browsers. There's a movement lately to moving this in to a shame.css though, which you can read about here: http://csswizardry.com/2013/04/shame-css/
And how do you decide when you will or will drop support for a browser version?
Google Analytics. Segmenting by browser type in Google Analytics is very useful. When usage for a particular browser drops below 10% it's a good time to stop developing new features for it.
You could do something as radical as throwing away all of your hacks/styles for that browser too, but for a smoother transition (and to encourage people to upgrade) it's better to simply stop developing for the older browser, and maybe conditionally display a message.
We dropped support for IE7 recently, and now visitors using IE7 will get a message telling them to upgrade, and they don't get any more fixes or additional features.
Mobile is a whole other kettle of fish, and if your site is completely responsive it's an extra layer of pain.
We've got a bunch of different size/version Android devices, a couple of old iPhones and an iPad kicking around the office that we use for testing the majority of mobile browsers on.
Obviously there are differences with screen size, DPI, browser version etc. The best you can do in this regard is cater for the most common case, and fix any issues as they surface.
design and develop with web standards. validate the web platform. all of the libs/solutions/etc., already listed are phenomenal and quite useful, but if you stick to standards, you'll find you need those libs less and less...at least for gracefully degrading user agent support. i find i use them more and more for progressive enhancement.
I'm developing a very simple web site, with only one web page, but i need the one single page to look as it should in all the browsers. Now, for testing purposes, i have installed a bunch of web browsers on my windows 7 machine (FF, Chrome, Opera, Safari, Netscape etc.) and after doing some markup changes, i've got the same looking webpage on all the browsers.
Now the question is, does "the way" a browser renders a web-page depend on the operating system the browser is running on? Should I install linux (or other os) and test again or it will just be fine?
You should definitely be testing sites cross-platform, others may disagree, but the rendering is definitely different.
In addition to base-rendering, you may also be missing fonts, have alternate fonts with the same name, have anti-aliasing enabled/disabled on different platforms/configurations and much more.
To see exactly what I mean, on a base install of Windows 7 with Firefox 5, OSX with Firefox 5 and Linux with Firefox 5, when using the font 'Arial' or 'Verdana', you will clearly see the differences, even if those fonts do exist on all platforms.
On top of the differences you'd see above, even your positioning could be out if you're using non-absolute values (hell, even if you are using absolute values such as px it could be out!), so it's always best practice to check your sites cross-platform, it's as important as checking cross-browser, in my opinion.
Even if the same fonts exist on different OS they might look different.
So yes if you want to be sure that the page look satisfactional on the OS you should test..
As rudi_visser said, you should be doing cross-platform testing. It's a bit of a bother, but absolutely worth it.
You can start by using a service like browsershots.org to quickly check if your site looks ok. To check older versions of IE, Microsoft provides some virtual machine images you can run in Virtual PC to really test the sites. Alternatively, there's this site which is like browsershots.org, only faster and IE-only. Please note, that screenshot services are no substitute for actually testing the site on a certain platform/browser, but it's a quick way to see if something's working at all.
I would definitely recommend checking your site in the older versions of IE, since IE has a rich history of, well, not working quite right. IE9 (which I assume you're using) is a big improvement, but a lot of people are still on versions 6-8. Since IE6 was around for ~9 years without major changes, IE 7, 8 & 9 have each had a lot of catching-up to do, so they're all very different.
As for other browsers, their rendering is more consistent across versions, but they may not be consistent across platforms. Again as rudi_visser said, elements might shift around, and especially text can look different. For instance, Mac OS X uses a different font-smoothing technique from Windows, so a line of text may appear longer/shorter, bolder/lighter from one to the other. A cross-platform browser like Firefox will use the OS' font-rendering, so even though the browser's the same on the different platforms, it can still look different. (The exception is Safari on Windows, which, I think, insists on using Mac-like font-smoothing instead of Windows' own).
This is a question to all web-developers working in the industry more than a few years.
Today the server guy at my work told me that his browser didn't render a Google font I used on a site properly, so I checked his browser - it was Firefox 3.5. (Google font Raleway).. This made me think.. I know for some of our sites its a requirement to support IE6 (larger corporate sites) but for the rest (personal sites) should I be looking at developing for all increments of Firefox, Chrome, IE and Safari?
Does your company still support IE6?
Does your company support previous versions of modern browsers or just the latest ones?
And finally, has anyone else had this problem with FF 3.5 and Google Hosted font Raleway..(the font displays extra extra thing so the font is almost unreadable)
http://fonts.googleapis.com/css?family=Raleway:100&v1' rel='stylesheet' type='text/css'>
If anyone's interested I found a working solution to my font problem here:
http://www.jshsolutions.net/google-webfonts-cross-browser-fix-howto/
Users of FF/Chrome/Safari usually keep their browsers up to date. Keeping antiques around like IE6 is a corporate thing. Some users keep IE7 and IE8 around due to their unnecessary fear of things breaking. We promise to support the current version of browsers plus one version backwards. If someone wants anything further back than that, there's an extra charge.
It depends entirely on the user base and also the size of the user base. For example , the user base for governrment sites will be substantially different to personal sites.
A site with 10,000,000 visitors per year with 1% IE6 usage should ideally cater for thoses users. But a site that gets 10,000 visitors a year with 1% IE6 usage could probably afford to ignore IE6.
You should always support the current and prior major release of Chrome, Firefox, Internet Explorer, Safari and Opera. If the client needs an older browser to be supported he should pay extra.
My company supports IE6 for our intranet website - but somewhat reluctantly. However, last quarter, they rolled out mandatory updates for XP systems (IE7 and SP3).
IMO, it is unnecessary to break your head over tweaking CSS for every version of the browser. I'd suggest creating CSS for major versions like IE7, FF3 and webkit-based browsers and have a disclaimer stating the minimum requirements for the website.
Alternatively, you can load content based on the user's browser. Nevertheless, it would be more tedious.
Importantly, check the current browser shares (http://www.netmarketshare.com/browser-market-share.aspx?spider=1&qprid=0) and decide which browsers you want to support.
Yes I am suffering from the same. We support IE 6,7,8,9 ,FF 3.6,4 and Safari. It seems to be the worst thing to write one code for all this browsers. I never understand why client use IE6. Check this http://ie6countdown.com/ will give you idea about how many are using IE6.
Is anyone writing applications specifically to take advantage of google chrome?
Are there any enterprise users who are considering using it as the standard browser?
Yes, I have started to pay very good attention to Google Chrome for my applications. Recent analytics show that between 6%-15% of my users are accessing my applications (varies between 6 to 15 in different applications) on Chrome. And, this number looks on an upward trend.
Thus, I can't really ignore it for testing right now.
As far as taking it as a standard goes, thats a long way off. I still have to test for IE6! :( Though, we have been planning to start using features like Gears (inbuilt in Chrome - downloadable elsewhere) once Chrome crosses the 25% mark. Thats when I believe that we will be looking at Chrome to be our preferred browser. I hope that we have Chrome 1.0+ by then! ;)
I switched to Chrome and haven't looked back except for the occasional site which doesn't work properly, forcing me to load it in Firefox. All my existing web applications work fine on it, and I'm using it for primary testing on my current development project.
I'm not actually targeting chrome, but I have added chrome to my browsers to test sites on. I've found some odd quirks in this product where some plugins cause the browser to hang, or run really slow in some environments, but they are still in beta in active development. But I definately now make sure sites I work on render well in chrome, as well as firefox, latest versions of IE, safari, Konquerer and opera. I usually check out how it looks on lynx as well, that helps me catch "un-alternated text" in images. Yeah, I know that isn't a word, but some people will understand what I'm saying.
Because chrome uses the webkit to render HTML, you can be assured if it works in safari, it'll work under chrome, however it's rendering engine isn't up to scratch quite yet. I think writing applications that take advantage of it is similar to writing iPhone applications, remember chrome is expected to be adopted by android to make it similar to iPhone. That way it pretty much takes advantage of all those iPhone apps.
Would I install it as the browser of choice? not yet - but i'll certainly work on valid web pages that will render across all browsers.
One of our major customers has outlawed Chrome because it installs on the C drive without asking. They deploy a standard image with a small C drive and large D drive so they can easily re-clone the system part of the image on C without destroying the client's personal files on D. Most software allows you to choose the install directory. Anything that violates this is disallowed, and they're a big enough company to have some weight with most vendors.
We have enough headaches trying to support
Firefox
Two versions of IE which have their own iffy bugs
Safari
I'm not sure why we continue to support Safari. Most of our users (corporate) use IE6 or IE7. We try to make sure that things work in both of those.
Maybe not for programming purposes but Chrome w/ Google Reader makes for the most powerful RSS reader. Can handle up to 1500 feeds w/ performance still ok, managing subscriptions still functioning.
I'm using it on my work machine, but that's about it. It's been stable for me, and I like the barebones UI. I'll still switch to Firefox for the web developer extensions however.
I'm liking some of GoogleChrome- the Start page with your 9 most recent is the winner for me. The interface takes a little getting used to, but the speed is impressive, especially with Gmail.
However, it glitches with Java, which rules it out for serious work at the moment. I use FireFox mostly and have Chrome for the "other" websites at work.
I'm considering using GWT on an intranet project and considering suggesting to the users that use Chrome to take advantage of the enhanced Javascript performance. Any AJAX-heavy app would be a great candidate to target Chrome.
At my company, we're not targeting it, but we're definitely paying attention to it. My boss is using it as his primary browser, and I have implemented browser detection for it in our scripts in case we ever to need to target it for some reason.
Chrome has the .png opacity bug where the transparent parts of the .png are a solid color if you try to transition the opacity from 0 to 1. In IE7 the opaque parts are black, and in Chrome, they are white. Today, I decided to go ahead and account for this bug in my JavaScript. I don't really test sites on Chrome that often, but I am actually using it for almost all of my browsing.
I will target Chrome as soon as a stable Linux and OSX client is available.
Targeting Chrome/Chromium right now, I think is like targeting Konqueror web browser. It will get popular, but you should wait to a more stable beta, and/or some Linux and OS X client.
My website statistics shows 3.xx % visitors using Chrome which arrived just few weeks back. And Opera is only 4.xx % which has been around for several years.
Easily you can see that rate at which Chrome is picking up.
You can see how easily Google takes over all areas of your computing world and personal world too.
Since Chrome uses Webkit, it has the same rendering engine and DOM support as Safari (not necessarily the same revision of Webkit though). By testing in Safari, you can generally get by without worrying about Chrome. Any differences you find are probably just bugs that you should file on instead of work around.
However, because Chrome uses a different JS engine, there may be a few incompatibilities with Safari. So, if you're doing anything with JS, you might as well fire up Chrome and see if there's anything obviously wrong.
Generally though, you don't target browsers, you target rendering engines (with their associated DOM support and JS engines).
I am using Google Chrome, so far all the web apps I have work fine in it with no modifications.
No.
Why help Google further build an evil empire? In this particular case it is so obvious that they do not care about users but only obsessed with gathering usage info.
It's not any major player yet