Elements Positioned Relatively Don't Move When the Dom Is Updated (IE6 and IE7)

Elements positioned relatively don't move when the DOM is updated (IE6 and IE7)

Yeah IE is a real pain when it comes to this. I found that I actually had to force it to redraw the DOM element inorder to get it to move. How I did this was to very quickly hide and show the parent object in your case it sounds like the parent to your row. This is not the most elegant solution, but it does the job.

In my case I used jQuery to get the job done.

var forceRedraw = function(obj) {
    /// <summary>Forces a redraw of passed objects.</summary>
    /// <param name="obj" type="jQuery" optional="false">The object for force the redraw on.</param>

    obj = $(obj);

    // force IE to redraw the obj
    if (jQuery.browser.msie) {
        obj.css("display", "none");
        obj.css("display", "block");
    }
};

IE7 relative/absolute positioning bug with dynamically modified page content

This is related to the "hasLayout bug" of IE. The relatively positioned #panel parent doesn't have layout and hence IE forgets to redraw its children when it get resized/repositioned.

The problem will go if you add overflow: hidden; to the relatively positioned #panel parent.

#panel { position: relative; overflow: hidden; border: solid 1px black; } 

In depth background information about this IE bug can be found in the excellent reference "On having layout" and then for your particular problem specifically the chapter "Relatively positioned elements":

Note that position: relative does not trigger hasLayout, which leads to some rendering errors, mostly disappearing or misplaced content. Inconsistencies might be encountered by page reload, window sizing and scrolling, selecting. With this property, IE offsets the element, but seems to forget to send a “redraw” to its layout child elements (as a layout element would have sent correctly in the signal chain of redraw events).

The overflow property triggers the element to have layout, see also the chapter "Where Layout Comes From":

As of IE7, overflow became a layout-trigger.

IE: element does not move when :hover makes another element visible

It was your comment about the position: relative that helped me solve it. That flagged me to think hasLayout! The issue seems resolved if you make sure both form and fieldset have layout set also (just giving it to the #link created the issue). One (among many) ways:

form, fieldset {zoom: 1}

See the working fiddle.

BTW: You should not have two #hover id's in your code. That should be set to a class (maybe it is just an error in your example, but I wanted to note it).

AP HTML element isn't removed from the normal flow of HTML in IE6 & IE7

while I can't reproduce the error, as in it's working fine in IE7 for me with the CSS as it is, you might try this, still accessible and just clips the content of the error message (is that what you want?)

#contact_form label.error {
  position: absolute;
  clip: rect(1px 1px 1px 1px); /* IE6 */
  clip: rect(1px, 1px, 1px, 1px);
}

what I might change is to not have that error message in a label - a form element should only have one label, as you're concerned with the best accessible hiding method - but changing it to a div or span should not affect the CSS (apart from changing e.g. label.error to span.error)

---

Update: per comments

I took the jquery.validate.js and
changed the line (207) errorElement:
"span", from label - then the above
code - #contact_form span.error - and
probably your negative left
positioning now works, for some reason
IE7 is picking up the span but not the
label?

Fix for background-position in IE

A bit more digging about on the Interweb has revealed the answer: IE doesn't understand the selector background-position. It understands the non-standard background-position-x and background-position-y.

Currently hacking something together to workaround it.

Nice one, Redmond.

Why is moving an element out of and back into the viewport affecting it?

I think it has to do with a hasLayout issue.

I was able fix the behavior in IE 7 (I dont have IE 6 on my computer) by introducing a height property to the style, to force IE to acknowledge it had a layout.

#navigation ul.primary-nav > li.top-level > a.menu-item-hover:hover span, 
#navigation ul.primary-nav > li.top-level:hover > a span,
#navigation ul.primary-nav > li.top-level.selected > a span{
    color:#fff;
    display:block;
    margin:-17px 0 0;
    padding:12px 7px 10px 15px;
    height: 21px;     /* this is what I added, in global.css */
}

Unfortunately, there is still a problem in terms of vertical position once you set the height on the element. You can play around with the top property, or subtract more from the margin-top property though to fix this.

Position Absolute div inside position relative list item - Clipping issue - ie7

Add a wrapper element

Updated Demo

If editing the HTML source code is an option, add a wrapper element around the side content, and place it before the main text content. Then add position:relative to the wrapper element rather than adding it to .listitem. This moves the local stacking context (created at an inconvenient time in IE7) to an element where it does no harm.

HTML

<div class="container">
    <div class="listitem">
        <div class="wrapper">
            <div class="layer">I'm a layer</div>
        </div>
        Some long content here bla bla blaaaaaaa bElements Positioned Relatively Don't Move When the Dom Is Updated (IE6 and IE7)aaa
    </div>
    ....
</div>

CSS

.listitem {
    /* position: relative; */   /* Removed here */
    ....
}
.wrapper {
    position: relative;    /* Added here */
    height: 0;
}

jQuery

If editing the HTML source code isn't an option, there are a few options available using jQuery.

1. Take the basic approach presented by @avrahamcool (setting the z-index of each .listitem to a decreasingly small value). The downside to this approach is that it reverses the layering order of the side elements relative to one another, which may or may not be acceptable.

2. Use jQuery to edit the HTML DOM so that the HTML is as shown above, using the related CSS changes as well. The downside to this approach is that the styling of the content won't render correctly until after the jQuery code has run. So the content may briefly appear broken when the page first loads.

3. Set .container to position:relative, rather than .listitem. Use jQuery to calculate the relative position of each of .listitem element within .container, and set the top position of each side element based on this. This approach has the same downside as solution #2.

4. In an extreme case, if even editing the JavaScript isn't an option, you could simulate solution #1 by adding a series of increasingly long CSS selectors with decreasing z-index values (as shown below). I don't recommend this approach, as it's wildly impractical, but it could be used as a last resort.

CSS

.listitem {z-index:99;}
.listitem + .listitem {z-index:98;}
.listitem + .listitem + .listitem {z-index:97;}
...

Conclusion

In short, the current HTML doesn't support this type of layout in IE7. The only elegant solution is to change the HTML source code to something that does support it. Any jQuery solution will tend to be awkward in one way or another.

Clean CSS fix of IE7's 'float: right' drop bug

Introduction

Your title indicates a desire to see a fix for the float: right drop bug, but your text implies some broader scope desire to see solutions to “problems with elements floated right in IE7.” There are many general problems with floated elements (right or left) in that browser. Even though one may question whether support of the IE7 browser is worthy of much attention any more, it undoubtedly will remain so for some people for some time. Therefore, I’m going to take the opportunity here to address numerous issues at once regarding floats in that browser. Note that many experiments and references below come from an excellent resource: http://www.brunildo.org/test/index.html.

CSS for the Containing Element

For a containing parent to the floated element the following css should be set:

.container {
    overflow: auto; /* forces clearing of the child float */
    zoom: 1; /* give it layout (this can be some other css that does likewise) */
}

Making sure it hasLayout is important to prevent types of margin and padding errors, a type of peek-a-boo bug, and allowing the overflow to clear. For a sequence of floats, some html may need changing if padding on the container is desired to work properly.

With regards to one “drop” issue with a float: right, you may want to avoid setting an explicit height or max-height on the container. A min-height is okay. Setting a height and then having the float be taller than the container makes IE7 not behave with following elements. There is no pure css solution that I have found noted.

If the container is itself position: absolute there can be issues with positioning a float that may require that float itself to be set to position: absolute instead of being floated.

References:

• For overflow to clear -- http://www.quirksmode.org/css/clearing.html
• Margins -- http://www.brunildo.org/test/IEFloatAndMargins.html
• Peek-a-boo -- http://www.brunildo.org/test/iew_boo.html and http://www.brunildo.org/test/iew_boo3.html
• Float sequence padding -- http://www.brunildo.org/test/IEmfloa.html
• Avoiding height -- http://austinmatzko.com/2007/07/25/internet-explorer-7-float-bug/, http://www.brunildo.org/test/fenc7.html (and his similar problem link on that page).
• Container is absolute -- Floating Too Far Right!

CSS for the Floated Child

For a the floated child element, the css (besides float: right) to set depends on two things:

Absolute Container

Again, as noted above, a containing parent that is absolute may require a change in how the child is handled.

Float is Also a Clearing Element

If the float is also going to have a clear set on it, then there are numerous issues that can arise depending totally upon the html and css of the elements around it. There is no single canonical fix, so look at the references below.

References:

• Container is absolute -- Floating Too Far Right!
• Also having clear -- http://www.brunildo.org/test/IEWfc.html, http://www.brunildo.org/test/IEWfc2.html, http://www.brunildo.org/test/IEWfc3.html

CSS for Child Elements of Container Before the Float

If the float: right follows an element in the html structure that should be to its left (and not above it), then that preceding element(s) must be float: left.

CSS for Child Elements of Container After the Float

A Clear Element

For an element after the float that has clear set, then if it has padding and background-color, make sure it also hasLayout to avoid a doubling of the padding; also this prevents extra space above the clear due to container padding, and avoids other margin issues.

References:

• For padding -- http://www.brunildo.org/test/IEClearPadding.html and http://www.brunildo.org/test/IEFloatClearPadding.html
• For margins -- http://www.brunildo.org/test/Op7_margins_float.html (look down the page for IE7)

A Paragraph Before a Clear Element

Having a paragraph with a margin-bottom and shorter in height than the float, located between the floated element and a clearing element, can create an extra gap between the clear and the float equal to that margin. There is no known pure css fix other than giving the paragraph a zero bottom margin (which may not be acceptable if the paragraph may go taller than the float).

Reference:

• Paragraph following -- http://www.brunildo.org/test/IEFloatClearMargin.html

Conclusion

I cannot guarantee I have addressed every issue that may occur with a right floated object, but certainly many major ones are covered. As to “why” these things happen, it is all “bugginess` in IE7.

---

Related Topics