Hello,

I have suffered that issue for a long time, and I just found out in your "known issues" page that this is caused by PIE forcing "zoom:1" to trigger hasLayout to true on IE < 8.

I couldn't find any subject about that issue on this forum, and wanted to discuss this: I have 3 questions to which I answered with my opinion, but would like to know yours please...

1) What would have happened if you didn't apply that "zoom:1;" property? would that prevent PIE from working? Would that break PIE's border-radius, box-shadow or linear-gradient?
=> I wanted to try that by myself by removing "zoom=1;" from PIE.js 0.5, and that doesn't change anything to the problem: top margins still disappear. Do you know why?

2) What would you suggest to people having problems with that?
=> For now, my solution is to replace every margin-top on elements with an equal padding-top on the elements' container. That works in most cases but that's annoying to do on a huge website that existed before PIE.

3) Do you have any ideas or projects about that issue in the future versions of PIE?
=> What about automatizing what I do in my 2nd question during PIE.attach(element)? Would that be possible for you, just on IE6 and 7, to "read" the desired margin-top, and adding it to the actual padding-top of the element's container? Or create an empty transparent div before the element which would have a height equal to the desired margin-top, and thus, would push the element downwards? Or maybe a wrapper instead of an "element before". (or even another way of which I didn't think?)

Here are HTML snippets of these ideas, that work for me:

Adding a div with the right height before:


Change the container's padding-top:



Add a wrapper with the right padding-top


(of course all that can be done in pure JS, these gross HTML versions are just to illustrate my ideas)

Thanks for your thoughts!

Good questions! My replies:



If hasLayout is not applied to the element, then that element will not fire any onmove or onresize events. This is problematic because those events are how PIE (primarily) detects changes in the element's layout so it can stay in sync.

It's possible that using -pie-poll would allow getting around that issue. I'm definitely open to making the forcing of hasLayout an option that can be disabled at the author's choice.

In your test, it's possible that hasLayout is getting applied to the element by some other means, such as a fixed width/height - see http://www.satzansatz.de/cssd/onhavinglayout.html#prop



Either a padding-top on the parent, or a margin-bottom on the previous sibling seem to be feasible workarounds in most cases.



I have given this quite a bit of thought. I don't want to implement your particular suggestion because in my opinion it makes too many modifications to the surrounding DOM structure, breaking the parent-child relationship between the elements which can cause other problems. There's one other option I've thought of that's a bit less invasive, which is when this scenario is detected PIE would insert a block-level element with zero height immediately before the target element; that should prevent the margin collapsing because the previous sibling would no longer be absolutely positioned. This should be fairly straightforward to implement, the trickiest part is detecting the scenario accurately. I just haven't had time to get around to trying it out. If you're willing to pitch in that would be appreciated!

Hi, thanks for your answers!



I tried that solution:



This doesn't work. I guess it's not a question of absolute positionning as you say.

Here is the fix I suggest:



Is that what you were thinking?


So,

The scenario to detect is just the case when:
- User agent is IE6 or IE7,
- The PIE'd element margin-top is > 0.

And the thing to do in that case is:
- Insert just before this element a div with height: 0; and margin-bottom equal to the desired margin-top.

(that's what I do with a conditionnal comment in my example, just to illustrate the principle with a working snippet.)


Is that enough?

No that's not quite right... because PIE will insert its position:absolute rendering element where I have marked, so it still triggers the problem. The extra div has to be inserted by PIE *after* its own position:absolute rendering element.

Your scenario is a good start but not quite complete, I'll add to it:
- User agent is IE6 or IE7, or a later IE in quirks mode (?)
- The PIE'd element margin-top is > 0.
- The element is display:block
- The element is not floated, absolutely positioned, or anything else that would take it out of block-level flow

I'm wondering too if this solution would break vertical margin collapsing rules... something else to consider.

oh, right, I missed these points... and I didn't consider everything... so finally, that IE6-IE7 bug is a very tough thing!

So, maybe, doing nothing and letting people write their CSS correctly would be better...?

Damn old IEs.

I didn't get the "insert a div *after* applying PIE" (I mean, I don't get why that would work), but if you say it works, fine, i'd like to see that!

Thanks for your answers.

Actually, elements with negative margin-top appear to have this problem, too. That is, the PIE'd element margin-top is not 0.

only bad people use negative margins!

... just kidding.

I recommend to avoid negative margins as IE6 hides anything of your element that gets out of the element's container.

Use position relative + negative top/left instead.

FWIW, the solution described above:

<!--[if lt IE 8]><div style="height:0px; margin-bottom: 20px;"></div><![endif]-->

works for me. I had a container and the floated content within the container was popping up out of the container, UNTIL I either moused over the box (ie6) or resized the window (ie7) at which it would pop back down where it was supposed to be. Driving me crazy. I messed with clear, overflow,a floats, position, everything... then I realized that when I shut off PIE, everything was fine, so it had to be a PIE issue. Then I scoured this site looking for a fix and trying to change the hasLayout/zoom without success.

You should add this fix to the FAQ!

Hi!

It's been quite a while, but I didn't forget this problem and am still thinking of a solution and a full test case as Jason asked me to do.

But in parallel, I'd like to ask Jason if he knew why this problem is presend with PIE, but it's not present in libraries such as DD_roundies.

Here's what I think:

If you inspect its project page on IE, you'll see that DD_roundies, like PIE, inserts an element (<ignore>) before the target element. But that <ignore> element is NOT in position: absolute. Its position isn't even set. Only its children (<shape>) are in position: absolute. The <ignore> element only has computed "left" and "top" values relative to its parent.

As a result, DD_roundies is compatible with margin-top on IE < 8, and it's also compatible with resizing / repositionning of the target element.

Why couldn't PIE do the same thing, when it inserts border-radius/background/box-shadow-related elements in the DOM ?

Thanks!

Interesting thought, I'll give it a look.