Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

An annoying IE position: Relative and OverFlow-Y Bug


:P
On this page:

A few weeks ago I posted a closable plug-in for jQuery and I’ve been using it in a number of places for list based close operations. It works well in most but I ran into an apparently known problem with Internet Explorer (pre IE8 Standards Mode). The closable plug-in works by injecting either an image or a styled div tag into the specified element and absolutely positioning it – typically in the upper right corner. The relevant code does something like this:

var el = $(this);
var pos = el.css("position");
if (!pos || pos == "static")
    el.css("position", "relative");
var h = opt.handle ? $(opt.handle).css({ position: "relative" }) : el;

var div = opt.imageUrl ? $("<img />").attr("src", opt.imageUrl).css("cursor", "pointer") : $("<div></div>");
div.addClass(opt.cssClass)

This works great with all browsers and in most situations even with old versions of IE. But  there’s a problem with pre IE 8 Standard Mode rendering of position: relative elements. Once position: relative is applied apparently these elements lose their ability to be contained in the parent container. As soon as elements become relative they spill out of the bottom the container regardless of the overflow or overflow-y settings.

You can see this first hand here with Internet Explorer in compatibility mode:

http://www.west-wind.com/WestwindWebToolkit/samples/Ajax/AmazonBooks/BooksAdmin.aspx

(it might be fixed by the time you look so here’s a screen shot)

BrokenRelativeElements

as you can see the content is simply spilling beyond the containing list. Basically there is an outer div (divBookListWrapper) that has a fixed height:600px and overflow-y: scroll set so the list should scroll whenever the content doesn’t fit. Inside of this element there are then a number of .bookitem <div> tags which render the detail content. The closeable plug-in then adds the position:relative as part of its processing.

This renders correctly in every browser but IE regardless of whether the .closable plug-in has been applied or not. In IE this also renders correctly if position: relative is not applied. Add position relative as part of the .closable plug-in (or just in markup) and the mess above occurs.

I’ve been mucking with this for a while, but I don’t see a workaround for this. The link mentioned at the top of this post mentions that quirks mode in IE is the only way around this. Oh joy. This is fixed in IE 8 Standards mode, but that’s of little solace given that IE 8 is still lightly used and that compatibility mode can easily be accessed. Also – annoyingly – the IE Tab and other IE plug-ins all use pre IE 8 rendering so the problem also shows up in IETab mode in FireFox.

In this case the solution is easy enough: Don’t use the plug-in and manually connect the delete button using a <div style=”float: right”> but this is not nearly as clean as the .cloasable plug-in which can be applied unobtrusively. Here’s the original template that top aligns the remove buttons:

 

<script type="text/html" id="item_template">  
<div id="divBookItem" class="bookitem">
    <div style="float: right;" id="divBookOptions">
        <img src="../../css/images/remove.gif" onclick="removeBook(this,event )" class="hoverbutton" />        
        <br />
        <small><#= SortOrder #></small>
    </div>
    <img src="<#= AmazonSmallImage #>" id="imgAmazon"/>
    <b><a href="<#= AmazonUrl #>" target="_blank" ><#= Title#></a></b>
    <br/>
    <small><#= Author #></small>
    <br/>
    <# if (Highlight) { #>
        <small><i>Highlighted</i></small>
    <# } #>   
</div>    
</script> 

If anybody happens to know of a work around that can keep the position:relative in place I’d love to hear it.

Things like this make me yearn for desktop development again. Nah, just kidding, but still I wonder when we can realistically start ignoring old versions of IE. What can we do to accelerate getting old versions of IE out of the Web? Purposely break sites with stuff like the above oughta be a good start – now if we could only get some of the big sites to do that so the turnover is quicker :-}.

Posted in CSS  HTML  

The Voices of Reason


 

Ryan Barlow
May 11, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

Hi Rick,

Giving the parent element (divBookListWrapper in your case if I'm reading it correctly) the style 'position: relative' should fix the problem. This works for the example(http://mt-olympus.com/emmett/bug_overflow_positionrelative.php?doctype=xhtmlstrict&overflow=scroll) also (class: scrollme).

Hope that fixes your problem
:-)

Jason Haley
May 11, 2009

# Interesting Finds: May 11, 2009

Interesting Finds: May 11, 2009

Steven Berkovitz
May 11, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

I'd actually never realized that this was a bug and instead have always been doing what Ryan pointed out - setting the container to position:relative too.

I've come across enough relative headaches to learn not to use them by now.

Nick Berardi
May 11, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

As Ryan stated "position: relative" in the wrapper is the way you fix this bug. It sort of makes sense, because with out the wrapper having position relative, the rendering is forced to use the document as the layout position. So the bounds of the wrapper wouldn't matter, because the elements are positioned in accordance to the document.

Nicholas
May 11, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

It's important to note that IE8's "Compatability Mode" != IE7's rendering engine. You're much better off using the IE7 Virtual PC image.

Rick Strahl
May 11, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

Thanks all. Confirmed that the position: relative on the parent container does indeed fix the problem in IE. Yay! Although not so yay for the .closable plug-in - certianly don't want to set position:relative any more than I have to. :-}

Siderite
May 12, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

How come you stumble on similar problems in the same time as me?! :)
Check this out:
http://siderite.blogspot.com/2007/10/absolute-position-of-html-elements-in.html
Just added the currentStyle part the other day.

I wanted to determine the position of a div with relative position on my page and I used the ASP.Net Sys.UI.DomElement.getPosition. And it worked on everything except on IE. Then I tried with my function (which at the time didn't have the currentStyle check) and got the same result as the Microsoft function. When debugging the DOM, I noticed that the style property of the div element had all the properties blank. You see, the div position was relative through CSS, not inline styling, therefore the position property was blank in style and 'relative' only in 'currentStyle', something I had no idea existed until two days ago. Added the check to my position function and now it works.

I know that you use jQuery (which I haven't tried yet), but what are the chances that their position function has the same issue?

Siderite
May 12, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

I mean the css("position") thing.

Barkha
May 12, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

http://ie6update.com/

Let's all band together and get everyone to upgrade already!

John
May 21, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

Hey I ran into this same problem - developed a nice little web application at work that basically has two different tables of data with headers on the top of each table. Each table has a scroll bar that you can grab and scroll without the headers on the top moving. Worked great in Firefox, Safari, Opera, and Google Chrome - as soon as I tested it in IE I encountered this bug that you are describing. I took a similar approach to the problem using two separate div layers - one for the header and the other for the actual table of data.

Anyway I fixed the problem using some Javascript:

Basically I have a function that does all the CSS stuff after the data has been processed and if it turns out that the client is viewing in IE then it will use a different procedure.

To test for IE I wrote up:

Returns True if the browser is IE
function isIE()
{
   return/msie/i.test(navigator.userAgent)&&!/opera/i.test(navigator.userAgent);
}


Then to fix the scrolling problem I had to do some special CSS for just IE that on the DIV that contained the table I wanted to scroll inside the window:

On the Div Containing the 'Windowed' Data
position:fixed;
overflow:scroll;
overflow-x:hidden


On the HTML Table Inside the Table that scrolls
position:relative;


Giving the data inside the DIV a relative position lets me change the positioning of it inside that fixed DIV and to my pleasant surprise this fixed that stupid overflow-Y bug that I was having.

Visual C# Kicks
May 21, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

Great read. How nice would it be to not have to deal with IE bugs

Marilyn
August 18, 2009

# re: An annoying IE position: Relative and OverFlow-Y Bug

Thank you for writing this. I'm dealing with this same problem. I have found that the position: relative fix works for IE6, and IE8, but IE7 is still displaying the absolutely positioned elements in the overflow: scroll div incorrectly. All browsers except IE7 are a-okay. Has anyone found a solution that works on IE7?

Chris
May 12, 2010

# re: An annoying IE position: Relative and OverFlow-Y Bug

Thanks very much for this I have been working for hours on a solution for this problem.

Piia
April 14, 2011

# re: An annoying IE position: Relative and OverFlow-Y Bug

I spend days for trying to solve this thing! Thanks to Ryan for this fix!!!
 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2019