Hi all.

I'm not sure this is the right forum for this, considering that I've got a problem and potential solution at the same time. Does already shot trouble go in trouble-shooting or not?

Anyway, having tried out PIE to give me border-image support in IE, I discovered that my borders and background were being drawn in the wrong position when the styled element had position: fixed. Specifically, the element in question was an immediate child of the body; I suspect the problem would not have occurred, or would have manifested differently, had that element been contained in another absolutely-positioned element.

So I dived into the PIE code to figure out what was going wrong. I discovered that PIE did not correctly calculate the position of position: fixed elements, only for elements positioned with respect to some positioned parent element.

So I changed the updatePos function of PIE.RootRenderer, and my tests so far show it to be working for me. Here's my version of the function...


Notice that I've set the position of PIE's element to be fixed if it is to sit behind a fixed element, and in such a case the document scrollLeft and scrollTop are not used to calculate position.

I have not, however, done anything about getting the positions right for IE6 (or earlier). IE6 treats position: fixed as position: absolute, which means that this would now produce an incorrect result in IE6 whereas before it would have worked (for a given value of "worked") in that browser. I figure for my current purposes, I don't care enough about IE6 to ensure that it gets the prettiest possible borders (no loss of functionality, just a little aesthetics, for that site), and if I did want to do something about it the best fix would probably to use conditional comments to produce an IE6-only stylesheet that replaces all the position: fixed CSS into position: absolute, so that the CSS matches the actual effect and PIE doesn't get fooled. (Or alter the styles with a quick bit of jQuery magic - after all, if PIE works, so does javascript, and since I've used some jQuery anyway...)

Now, I'll just build my own version of PIE to incorporate the fix, and I think I'm good to go.

So, can anyone guess at problems I might have missed? Either that my fix hasn't covered, or that I may have introduced with my fix? I'm guessing that there might be issues with fixed-position children of absolutely-positioned elements, but haven't done my testing to check.

And might I suggest that such a change as I've made be incorporated into a future version of PIE? If it's a good solution and hasn't introduced further problems, of course.

Thanks a lot for this, Travis, it's a great help.

Would you mind opening an issue ticket in GitHub for this? That will make sure it doesn't get lost and serves as a checklist for me.

Reading over your code changes I think you're right that it works fine if the position:fixed element is a child of the body, but if the position:fixed element is a descendant of another positioned element then it won't work right because it still subtracts the position of that parent element.

Actually I think that if it's position:fixed we can shortcut past all the getBoundingClientRect stuff and just use the left/top/bottom/right currentStyle properties of the target element directly (except in IE6 of course, which we'd let fall through to the current code). Do you see any problems with that?

I'd also want to verify that this method of positioning responds correctly when the element moves due to animation etc.

Sure, will do (though probably not until late tonight).


Yep, that's what I've been suspecting.


Yes, you're probably right there. That'd cover both the descendent-of-positioned-element case and the descendent-of-window case, wouldn't it? I did think about reading the style of the target element, but at that stage wanted to make as few changes to the original code as possible. (I'm not yet familiar enough with how it works to want to makethose bigger changes.)


I haven't tried it with animation as such, but I have used it with an element being moved via javascript. The way I noticed this was I had an element that I wanted to move with the window scroll until it reached a certain point and then stop there. At that point in the scroll, I changed how it was positioned, and suddenly my PIE-rendered background jumped to a completely different position on the screen. After my fix, it doesn't do that, so I know the new positioning method works when an element is repositioned via script.

But retesting for actual animation would be wise. It could look quite odd to have an element and its background move from one position to another via different routes and meet up at the end.

Thanks, Travis, I'll try to get your changes integrated when I have time.

Yeah, no problem. Don't rush yourself. The reason I put some work into diagnosing the issue is so that I can fix it myself, for my own purposes, straight away, so I'm not affected by the wait for you to fix it. With the sample code I posted, others can do their own temporary fixes too.

And thank you for what you've already done on PIE. Even if it isn't (yet) perfect, it's still a lot less work than implementing the same stuff from scratch.

Using the latest GIT code [Version 1.0beta3-SNAPSHOT Sep 10 2010] - I was having fixed-position problems.

I added the single line below (===>) to RootRenderer.js:



This change fixed my layout + positioning problem!
Prior to this code change, I had elements 'growing' large.