Menu
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)
757
NOTE: I've altered the order of your questions to leave the longer answer at the end.
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.
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:
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.
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.
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.
159
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:
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.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
