May 22nd, 2006

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 overflow to auto gave them the iframe they were looking for without all of the problems associated with iframes.

The problem arose when testing in IE6/Win on a particular page containing a form with various inputs, selects, and 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.

 Comments

4 Comments

  1. P.J. Onori May 22nd, 2006

    Good stuff to know. I usually don’t do too much with forms, but this is definitely useful info.

    Nice work.

  2. Jon May 23rd, 2006


    Author

    @P.J.: I find myself working with them constantly for clients. It seems that everyone wants a contact form and some other type of information request form on their site. I believe, however, that the bug affects any relatively positioned element in a container that is set to overflow:auto so that’s something to keep in mind too. Thanks for stopping by and commenting.

  3. Rowan May 24th, 2006

    Gah, don’t get me started on IE!

    I now know that the IE team are aware of this bug (I think it was news to them when I reported it on Connect).

    They said they will simply not fix it for the final release of IE7. This really infuriates me as it’s such a simple bug and sometimes using position:relative is the only way to make something render correctly in IE.

    But just so you know, this known bug will not be fixed anytime soon.

    Btw, I’m glad my bug report helped. ;)

  4. astridas May 26th, 2006

    This is really great to know. Thank you for taking the time to point it out to the rest of us who haven’t had the opportunity to run into this bug.