StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p><strong>What suggestions do you or your team have for testing new browsers as they come out?</strong></p> </blockquote> <p>As part of our <a href="http://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done" rel="nofollow">definition of done</a> we support the following desktop browsers:</p> <ul> <li>IE8+</li> <li>Firefox 3.6</li> <li>Firefox (latest)</li> <li>Chrome (latest)</li> <li>Safari 6</li> </ul> <p>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.</p> <p>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.</p> <p>To test Firefox versions on OS X I use the "<a href="https://github.com/omgmog/install-all-firefox" rel="nofollow">Install all Firefoxes</a>" script that I created, to allow me to run multiple versions of Firefox side-by-side.</p> <p>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.</p> <p>These virtual machines were setup using the images provided by <a href="http://modern.ie" rel="nofollow">modern.ie</a>. 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.</p> <blockquote> <p><strong>What things do you do during development to decrease possibility of having code break when a browser update comes out?</strong></p> </blockquote> <p>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.</p> <p>If we're using experimental CSS features, we ensure that we're providing vendor prefixed and lastly w3 definitions of properties:</p> <pre><code>-moz-foo: bar; -ms-foo: bar; -o-foo: bar; -webkit-foo: bar; foo: bar; </code></pre> <p>Obviously this introduces some technical debt, but if you're using a preprocessor for your CSS, the overhead of this can be reduced.</p> <p>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 <code>shame.css</code> though, which you can read about here: <a href="http://csswizardry.com/2013/04/shame-css/" rel="nofollow">http://csswizardry.com/2013/04/shame-css/</a></p> <blockquote> <p><strong>And how do you decide when you will or will drop support for a browser version?</strong></p> </blockquote> <p>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. </p> <p>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.</p> <p>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.</p> <p>Mobile is a whole other kettle of fish, and if your site is completely responsive it's an extra layer of pain.</p> <p>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 <em>the majority</em> of mobile browsers on. </p> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload