As someone who currently works in a team that is located close to the front end of a large web application, I am at times exposed to issues related to Internet Explorer and its numerous bugs, including (but not limited to) parsing, stylesheets, Javascript or rendering.

Today, my now least favorite tester (kidding:) dropped the aforementioned type on me before I could run:

On IE7, and only on IE7, there appears to be a white, 5 by 1 pixel line between the first and second image of the WasteTheUsersBandwidth feature. But only if you zoom in or out. The line is not visible at a regular zoom level and does not change in height at any other zoom level.

Jackpot. After reproducing (the bug) and issuing the appropriate WTFs, I reflected on some of the approaches I had taken in the past. In chronological order:

  1. BFDIED (Brute Force Driven IE Development). Trial & Error until the ‘correct’ (but secret!) HTML/CSS/JS combination is found (~?h)
  2. Reduce the problem to a minimum reproducible version (>0.5h), ‘understand’ the IE bug (~?h), locate places in respective specs and standards that ‘prove’ IE wrong (>0.5h), bash IE in emails & on web 2.0 (∞h), and, eventually, if a suit asks nicely, work around the bug (<0.25h)
  3. Disavow the sucker. Procrastinate indefinitely and argue that there is no business value in fixing it which obviously implies its non-show-stopper status

Number one and two are extremely frustrating and most often incredibly time consuming. Three does help developers maintain sanity but does not really solve any problems.

So this time I decided to try a new ride. Well aligned with our agile methodologies, I allotted myself a creativity time box of 15 minutes before falling back on 3, 2 or 1. Because of the zoom quirk, I was convinced that it must be a rendering issue. Still, for the sake of creativity, I searched the stylesheets for border, underline, 1px, white, #FFF, #FFFFFF, etc.

Bingo. Turns out both text-decoration: underline and color: #FFF were cascaded to the elements under investigation. That, in combination with what seems to be known as the ‘IE Whitespace Bug’, caused our white-zoom-lines. I removed these styles and had committed my changes before the 15 minutes were up.

This legendary success story taught me a lesson. Bugs (in software) are by definition illogical and irrational so maybe open-minded, non-routine approaches work better than the standard operating procedures. My next debugging session will definitely take place outside the box first and followed by the default weaponry (15 minutes) later.