A More Obscure Render Bug
From time to time I will come across as cross-rendering issue that takes me by surprise. I’ll spend a fair amount of time trying to solve the problem using semantic code and valid CSS to try and support the particular browser (read: Internet Explorer) and get nowhere. It is at that point I’ll ask colleagues if they had ever run into the issue and if so what advice they can give to help me out a bit. When they have no idea, it is at that point when I realize we might have a problem.
Discovering Render Errors
I like to think that I have a decent grasp on what to expect when it comes to rendering errors in various browsers (read: Internet Exploer) and try to avoid these issues from the start when I am writing my initial markup. However there are times where client requests lead me into situations I wouldn’t normally be in which create a playing field for various issues I had never experienced before.
For example, the specs of a recent project stated that the client would like their content in a container possessing a scroll bar for any content that extends certain dimensions. That isn’t a problem, simply setting the
auto gave them the
iframe they were looking for without all of the problems associated with
The problem arose when testing in IE6/Win on a particular page containing a form with various
textareas. I am a big fan of Khoi Vinh’s Subtraction Form. After a few personal touches, I have used and reused that technique many times and it has worked really well.
Resolving the Problem
As it turned out in this case, it was using the Subtraction technique that caused my troubles in IE6/Win. The
selects within the
form appeared to have a
position:fixed and it was driving me nuts. I went through my usual process of altering the markup and style in an attempt to resolve the issue, but got nowhere. A colleague hadn’t come across the issue before, so it was time to ask Google. After some searching I came across the following bug reports:
Closing Things Up
As it turned out, my
selects were relatively positioned for more accurate placement within the
form which was causing the issue. This is one of those rendering bugs that I had never come across before but are still major issues with IE6/Win. I have not tested in IE7 yet, but plan to do so and post the results, unless a reader does it first.