Skip to content

Retroactive Browser Compatibility

When working on an existing web application you may be placed in a situation where you need to support new browsers, or just other browsers that your app wasn’t originally coded for or tested in. In my case, this took the form of a web app developed exclusively for Internet Explorer that now needed to support other browsers. As I went through and corrected many of the browser incompatibilities, I noticed a few common ones, and wanted to mention them in case it’s beneficial to others in the same situation.

I should mention up front that jQuery was an indispensible tool when I was working on this project as in many cases I was able to replace the offending JavaScript with a jQuery equivalent that was cross browser compatible. If you’re a web developer and are not familiar with jQuery, you probably should be. ;-)

So a couple of things to look out for… I wanted to list the easiest ones to spot first as you can do a text search and usually find all of them:

  1. CSS Expressions:
    • Were implemented in IE5 and allow you to assign a JavaScript expression to a CSS property.
    • Were deprecated in IE8 standards mode, see http://blogs.msdn.com/ie/archive/2008/10/16/ending-expressions.aspx for details.
    • IE specific.
    • Search for: “expression(”
    • Replace with JavaScript that dynamically modifies the CSS properties in response to specific browser events (onresize, etc).
      • In many cases this can be more performant than CSS expressions because you can choose to bind to specific events (CSS expressions are reevaluated *every* time a JavaScript event with at least 1 listener fires.
  2. outerHTML:
    • “Get or set the HTML of the entire node x, including the outermost tag (element x itself).”
    • Example: x.outerHTML = “Let’s <u>change</u> it!”
    • IE specific.
    • Search for: “outerHTML”
    • Replace with innerHTML or W3C DOM methods. innerHTML is in theory faster, but IE and Konquerer have some issues when innerHTML is used with tables. Replacing outerHTML with calls to innerHTML will also require some changes to the logic using outerHTML as innerHTML is slightly different in behavior.
  3. Visual Filters:
    • Used commonly to create gradients without using images.
    • More information on Visual Filters: http://msdn.microsoft.com/en-us/library/ms532853.aspx
    • IE specific.
    • Example: <ELEMENT STYLE=”filter:progid:DXImageTransform.Microsoft.Gradient(sProperties)” … >
    • Search for: “DXImageTransform”
    • Replace with… Unfortunately there really isn’t an equivalent for this. Some of the visual filters can be replicated using standard CSS properties, but not all of them. As convenient as the visual filters are, they will only work in internet explorer at the moment.
  4. Window.Event:
    • Used to access JavaScript event information in IE.
    • IE Specific.
    • Search for: “window.event”
    • This item could have several pages written about it, but the short story is that IE handles passing JavaScript event information differently than other browsers. You will need to code your JavaScript to accommodate this difference. jQuery can again be useful here as it can abstract a lot of this problem away from you. I recommend reading the section on events here: http://www.reloco.com.ar/mozilla/compat.html as it will give you an overview of the problem and how to address it.
  5. Custom Attributes:
    • Used to defined custom element attributes.
    • Getting or setting custom attributes without using DOM methods is not cross browser compatible.
      • Example: element.MyProp = “This doesn’t work in all browsers.”
    • Search for… No good search string for these. You just need to keep your eyes out for JavaScript that makes calls to custom attributes without using DOM methods (or jQuery).
    • Replace with: calls to .getAttribute(“MyProp”) or setAttribute(“MyProp”) or if using jQuery, element.attr() as shown here: http://docs.jquery.com/Attributes/attr.

This list is by no means exhaustive, but I wanted to point out many of the common issues I have come across. Your mileage may vary. I recommend checking out the references listed below for a lot more good compatibility information. I’ve tried to check all of my facts, but if you notice anything that seems off, let me know so I can fix it!

References:

  • http://www.reloco.com.ar/mozilla/compat.html – “Making your web browser compatible with Firefox”
    • A good overview of many of the common browser compatibility problems faced when making an web app written for IE work in Firefox
  • http://www.quirksmode.org/compatibility.html – “Compatibility Master Table”
    • The holy grail of browser compatibility information. Seriously… Want to know if a browser fully supports CSS2, CSS3, DOM, etc? It’s here.
  • http://reference.sitepoint.com/ – “CSS/HTML/JavaScript Reference”
    • Reference site for CSS, HTML, and JavaScript information. Its got a clean layout and additionally contains browser compatibility information for each of the items.
  • http://blogs.msdn.com/ie/archive/2009/03/12/site-compatibility-and-ie8.aspx – “Site Compatibility and IE8”
    • A page detailing potential issues and fixes for making your pages compatible with IE8 in Standards Mode. This is actually a good reference for potential cross browser problems as most of the items listed are cross browser compatibility issues as well.

Official jQuery 1.3.0, 1.3.1 Visual Studio Intellisense Files

It looks like this weekend while I was at the South Florida Code Camp the jQuery team has posted the official jQuery 1.3.1 Visual Studio intellisense file. You can get it from the jQuery downloads page, or more directly from the jQuery Google Code download page.

The official 1.3.0 documentation was posted this weekend as well and is also available from the downloads link above, or this Google Code download page.

Keep your eyes peeled for a jQuery 1.3.2 release anytime in the next few days as John Resig has mentioned there is still one last 1.3 regression they are working on fixing.

For those interested, the regression has to do with the $(document).ready() function waiting until images are fully loaded in Internet Explorer 6 & 7. The jQuery bug ticket ID is #3988 and here’s a Stack Overflow question in which John Resig talks about the issue in some detail.

Making ReSharper Play Nice With StyleCop

I’ve been toying with StyleCop more and more as of late and ran into some situations where ReSharper and StyleCop were fighting each other over code formatting issues. Some manual tweaking reduced the problems, but it got me curious. So I did some research and uncovered a wonderful tool, StyleCop for ReSharper.

StyleCop for ReSharper is a ReSharper 4.1 plug-in that allows Microsoft StyleCop to be run as you type, generating real-time syntax highlighting of violations. StyleCop for ReSharper also contains a collection of Quick-Fixes and Code Clean-Up Modules to help you easily fix StyleCop code styling violations.

StyleCop for ReSharper also comes with a ReSharper Code Style Settings File which you can import into ReSharper to make ReSharper’s auto formatting features compliant with StyleCop’s recommendations. If you don’t want to import a whole code style settings file and would rather just tweak some specific formatting settings that are responsible for most of StyleCop’s complaints about ReSharper, I recommend reading these 2 blog posts at Hock Blogs:

Navigating around the StyleCop for ReSharper project page on CodePlex also turns up a lot of additional useful information:

All in all, I’m enjoying this ReSharper plug-in. It has taken a lot of the pain out of being compliant with StyleCop’s rules.

FxCop 1.36 and StyleCop 4.3

While this is not new news, I realized that finding the link to download FxCop 1.36 is still not as straight forward as I’d like it to be (most links are still pointing to the 1.35 on msdn code or the 1.36 Beta 2 release), so I thought I would add the link here so I can find it again, or anyone else for that matter.

For those who haven’t used it before, FxCop is a tool to analyze .NET assemblies based on a set of rules in order to find potential defects or design issues. The tool comes with a lot of very helpful built in analysis rules that are broken out into seperate categories (e.g. Performance, Design, Globalization, etc..). A lot of Continuous Integration tools have the ability to include FxCop analysis as part of a build so that the warnings FxCop generates can be tracked over time (hopefully in the *downward* direction).

And on a somewhat related note, I also wanted to add the download link for StyleCop, which ironically, is easy to find even though I’m pretty sure a lot more people are using FxCop.

StyleCop is a tool which analyzes C# source code using a set of rules (much like FxCop) in order to enforce code styling guidelines. It can be used in Continuous Integration projects to verify code style rules are being met. The rule documentation is also available at the link above. I have found reading the rule justifications to be quite educational at times, especially since many of the StyleCop rules run counter to common .NET programming practices that I’ve seen.

Unofficial JQuery 1.3 Visual Studio Intellisense File

In lieu of the official Visual Studio 2008 Intellisense file for jQuery, the jQuery intellisense file generator at http://www.infobasis.com/sandpit/jQuery-Intellisense/ has been updated to support jQuery 1.3.0 (See this post for more details). The will allow you to get proper jQuery 1.3 intellisense in your applications until the official version is released. The above linked script generator uses the official jQuery API documentation to build the intellisense file, so you don’t need to worry about it being inaccurate or imcomplete just because it’s not the “official” version.

Happy jQuerying!