Check out the latest SQL Server show –
Watson! You may have seen him on Jeopardy! – Stephen Baker joins us on the show today talking about what was learned with the project. Stephen Baker wrote the book (literally) on the Watson project and all that it entailed – do not miss this show…[Watch the Show]
Javascript With Multiple Browsers in Mind
It seems like multiple browser support isn’t getting any better. The techniques our readers are submitting for handling multiple browsers is neither foolproof or elegant. Basically, a lot of if statements for handling things that are browser specific.
Worse yet, one reader has found Microsoft has changed the way older versions of IE used to identify themselves breaking their switching logic.
As Microsoft seems to be losing market share in the browser field the need to support multiple vendors is growing, and techniques for handling the differences is increasing.
I’m curious if there isn’t a tool or development pattern that better suites the browser code than If Browser = x statements? Is it possible to manage the differences and build the appropriate JavaScript and only return the JavaScript appropriate for the consuming browser? In short, pre-calculate the IF statements and return only the code specific to a browser.
Here are some of the responses from our readers…
David E Writes:
Personally, I think MS has really dropped the ball here on this. A very recent example:
A new intranet site is being developed for our office and I’m one of the main developers. Supporting every browser other than IE has been a breeze; once we get it working in Firefox, it has always worked in Chrome, occasionally needed a tweak here or there for Safari, and a bit more often for Opera (but we only made fixes for Opera if they were easy, not targeting anything other than the “default” browsers on the various operating systems [IE -> Windows, Safari -> Mac, Firefox -> Linux]).
I much appreciate the changes IE8 and IE9 have made, as most of the time, I don’t need an IE9 codepath, and only occasionally do I need an IE8 codepath.
But rather than just mark the IE6 ways of doing things in Javascript as deprecated, Microsoft has actually removed these features if you want the rendering engine to otherwise match the non-MS browsers.
So, we use the navigator.appVersion value to determine which browser we are running in, then execute different codepaths for IE7, 8, and every other browser (we got the okay to eliminate IE6 for this application).
But just last week, a patch was pushed down that forces all IE8 browsers to identify themselves as IE7. This is not the IE7 standards mode or the IE “quirks” mode being forced, only the appVersion value changed. According to the IE developer tools, the document mode is “IE8 standards” and the browser mode is “IE8 Compat View”.
This completely ruined the IE7/8 codepath differences because even though IE8 identified itself as IE7, it still rendered everything as IE8! So, all of the Javascript we wrote to alter the look or behavior of the intranet site to handle IE7’s quirks was now causing havoc on the testers who were using the (at that point) most recent release of IE!
Fortunately, we were able to find a DOM element that exists in IE8 and this “IE8 Compat View”, but does not exist in IE7 nor IE8 in IE7 standards mode, document.querySelectorAll, so now our codepaths are running correctly in IE, again.
I would like to contrast this with Firefox 4.0, which still renders pages I wrote in the 90’s for Netscape Navigator 4 correctly. Say what you will about the chubby browser, Mozilla understands the need for backwards compatibility for web browsers just like the Windows team does for operating systems.
Shannon Writes:
I work at a research hospital specializing in pulmonary and allergy treatments and research and my job is primary data and functional QA of our Research Database, which is a data warehouse that connects the EMR and research study data and provides a web-based front end that allows researchers and physicians to search the data. We faced the dilemma of what to test on and it was determined first by what our users were most likely to be using (I’ve asked the developers and the network engineers to gather stats on browser usage for me but they haven’t found the time).
Here, the EMR software, Allscripts, only runs on IE 7 and is not compatible with IE 8, thus, our IS department will not support IE 8+. So, IE 7 went on the list and we added IE 6 for backwards compatibility as most of our users care more about patients and research than technology, so we figured they’d be slow to move forward. Our researchers could be running anything in their labs. Most researchers either have Macs or Linux boxes in order to run statistical analysis software (the best open source stat software is usually Linux based), so we added Safari 4.x and Firefox 3.5.
We use Selenium Server for functional testing and found that it works well with Firefox 3.5, and 3.6, and mostly OK with Safari 4, but horribly with IE 6 and only moderately better with IE 7. We ran through most of our testing suite using Firefox 3.5/3.6, and Safari 4. Firefox we test on virtual machines, Safari on a cast-off craptop we found lying around (we figured it would most resemble the machines found in labs). IE 6 and 7 we set to run on the same two virtual machines we test Firefox on, but discovered that in IE 7 xpath (which we use in Selenium to find screen elements) is painfully slow. Once we got our functional test suite up and running and located as many browser incompatibilities as we could and fixed them we went back to testing only Firefox and Safari for releases … we feel this is OK because our developers keep IE 6 or 7 on their development machines and thus see it on a daily basis so are more likely to catch issues and we do monkey testing prior to releases with all team members banging away with their local browser – we all try to use a different one, which is easy because we all seem to have different preferences.
I guess what I’m saying is that it comes down to an art more than a science and we try to keep our code as browser neutral as we can, but since our users aren’t into bleeding edge browsers, we don’t have to be either.
One issue that comes to mind in testing is screen resolution. Automated tests can’t really help us find those issues since it doesn’t "see" like a human. And most of the development team works on not one, but two, high-resolution monitors. We have a minimum resolution of 1024×768, which one of our developers claimed to have tested, but recently I watched a user in action and found that our minimum is not high enough as it was causing triple scrollbars and, shamefully, a horizontal scroll bar hiding out of the vision of the user. Unfortunately, with the economy and our organization dependent upon benevolence for most of our operating funds, the capital budget prevents many of the researchers from getting new monitors anytime soon. This leads us to have to go back and redesign to "create" more screen real estate for the users on a smaller monitor.
David B Writes:
Our situation may be a useful case study of cross-browser development:
We’re a 3-person team maintaining a mission critical Web-based app for a 350-person company. Most of the employees are network engineers so they’re always running betas of a wide variety of browsers, on every OS and hardware platform.
When we set out to do this 10 years ago, a primary goal was to be browser-agnostic. We do everything we can do write simple HTML to basic standards. Only once or twice did we write a feature that knowingly would only work in a certain browser. This means of course that our app is less "sophisticated" than it might be… we’ve never done anything with ActiveX, Silverlight, Flash or Ajax. Even the most rudimentary attempts to do anything "cool" in screens have proven to be ugly… anyone who says the Javascript or CSS object models are "standards" has never had to write "If browser = IE then do X else if browser = Firefox then do Y else do Z". If we had a larger team we could have one person really focused on getting all that to work and we could do more.
Our developers work in IE (still 8, not 9 yet), and that is our "official standard". We guarantee that everything will work in IE, and we don’t formally test our day to day work in anything else. When we do some new code with CSS or Javascript we do test it against the whole range of browsers: IE, Chrome, Firefox and Safari on Windows, Mac and iOS. But we don’t block use of other browsers. We encourage all our users to report any issues they see, and tell us which browser they’re using. We try to fix all the issues that come up, but we jump on IE issues faster than the others.
I’m the team leader and I mostly work in Chrome (by choice… I like its speed), so my day to day use of our system makes me effectively the tester of compatibility. I just remember to launch another browser for the 2 or 3 things that I know don’t work in Chrome that aren’t worth taking the time to fix.
Steve says:
We have limited our browser support to cut off with IE7. We do not support IE6 for our public facing web projects. We generally code for IE7, IE8, Firefox and Chrome. Safari seems to be fine with the Chrome coded sites.
For IntraNet applications, we will support older browser versions and we charge extra for multiple version support.
We test using VMWare with multiple virtual machines running different versions of OS/browsers.
Are there any tools out there that help you write to a more generic set of code? Has anyone developed in house techniques or tools? Drop me a note at facebook, twitter, or email at btaylor@sswug.org.
Cheers,
Ben
Featured Article(s)
Top Ten Database Blunders (Part 4 of 4)
As a PTO (Performance, Tuning, and Optimization) consultant, I’ve seen some pretty crazy problems. Although the names have been changed, these stories are true. You’ll hear me rank the 10 worst real-life blunders, why they’re so expensive, and how to avoid them in your career.
Featured White Paper(s)
Essential Performance Tools for SQL Server DBAS
Optimizing SQL Server performance can be a daunting task. Especially so for an increasing number of reluctant DBAs faced with… (read more)
Featured Script
dba3_0060_hr_Set_MoveSets_Article
Creates stored procedure hr_Set_MoveSets Used in demonstrating manipulations of a Maps and Sets logical design of a hierarchi… (read more)