Position-fixed in IE6 with "expression()" and no jittering

As I said in the other thread:

I came across this simple solution, as well. It uses css expressions. But perhaps IE 6 deserves to be 'punished', I don't know, for not supporting fixed as it should. Ironically, fixed, actually is used.

So in the BODY:

background: url("https://") fixed;

And in the style for the top bar:

top: expression( (( t=document.documentElement.scrollTop) ? t: document.body.scrollTop) +'px');

And that's it. Fixed at the top. And no jitters. It works quicks or strict in IE6. And I'd only load it conditionally for IE6 (maybe 5).

As you explain, it would make sense that updating is done first, because that's what we see - no jittering. The https is apparently needed because http could cause a problem. But you don't actually need a background image.

I like having the option of different background tiled images, selected from a preferences menu. But it's not applied to the body, but to a div named, container (or comtainer, or whatever have you), that's become fairly standard practice. So the child of BODY, is this container div. It's got a few of its own 'containers'. But it, rather than body, tends to be treated as the topmost element.

Your inline script does a lot of validating. But could that be more clearly accomplished in the css itself? If you want no margin, just set margin:0 ?

As with you, I have no problem writing a main css, and then loading a fixer css for the down-level IE6. So all this would go in that IE6 specific css, too. As for how to call it, I don't mind calling from the hard coded page. These are typically all generated anyway. So change the template, and regenerate them all again. BUT once the site become substantial, I would agree, you'd want this done just in the main style sheet, once, and that's it. Apparently there are various import hacks for IE6. The problem would be if another browser, or IE8, 9, etc, overlook the hack and load the css. But since this import is only in one place, in one file, I think it's worth the risk. If it needs repair, in future, you know right where to go, and before and after it's good for every old/legacy page on your site.

I noticed particularly with margin, that zooming in/out in IE6 can disturb the relative placement. A item at the bottom of the navbar winds up near the top at full zoom, etc. But that's even true with 0 margin. They still slide around too much. The script module I suggested doesn't do this. Even at full zoom, the various 'fixed' elements are about where you'd expect them to be on screen (with 0 margins set). But of course, they 'jiggle', they 'jitter'. But since the main navbar is now free from that, the distraction might not be as much.

fside, your solution needs a container. My solution keeps the markup untouched. 4 lines of style specific to IE6 and you're done.

If you use the correct conditional comments to target only IE6, I don't see how you would need to correct the style once IE8 IE9 are available.

Your inline script does a lot of validating. But could that be more clearly accomplished in the css itself? If you want no margin, just set margin:0 ?

My script (anti-jittering) checks the current layout of the page. It doesn't touch or add margins (in fact, it doesn't even care). There is one remark about margin on BODY, and it could be used as a trigger for an alternative method which would preserve the background-color/background-image duo.

I noticed particularly with margin, that zooming in/out in IE6 can disturb the relative placement.

I don't see this in my test case.

[edited by: Achernar at 1:34 pm (utc) on Mar. 6, 2008]

Thank YOU! Works like a champ in all browsers. In my case, the implementation is via javascript:

if (element.style.setExpression) { // IE
element.style.position = 'absolute';
element.style.setExpression('top', "(document.documentElement ¦¦ document.body).scrollTop +'px'");
element.style.setExpression('left', "(document.documentElement ¦¦ document.body).scrollLeft +'px'");
document.body.style.backgroundImage = "url('/pixel.gif')";
document.body.style.backgroundAttachment = 'fixed';
}
else element.style.position = 'fixed'; // !IE

[edited by: MarkFilipak at 8:33 pm (utc) on Mar. 6, 2008]

>If you use the correct conditional comments to target only IE6<

I agreed with you. I like the idea, though, of doing this in just one place rather than using IE conditionals on every html page. Most of these are hard-coded by an offline generator, not created at the server.

Instead of the slash/underbar hack, perhaps one could use script to attach to the HEAD. Script has to be on, anyway, for this to run.

>I don't see this in my test case.<

Do you have an example of two or three divs that have to be fixed in some relative position to each other. And when zooming in or out in IE6, do they go out of position? Let's say you float a copyright string to the bottom of the navbar. Let's say you have an auxiliary menu on the left, about a "W"s spacing below the bottom of the navbar. And you've got your own custom status bar at the bottom.

Achernar, thank you so much for taking the time to post this, great post!

I like the fact it can be completely separated and although I haven't read and digested it all yet, I have a question.. I'm not too hot on javascript so excuse my terminology.

I recently heard and have read previously that CSS Expressions continue to execute on every mouse move/user action/window scroll etc but that you can stop that happening or lessen the server calls by making sure something is done in the expression, is that what you mean by

>>We have to ensure that the enclosed javascript code is completely evaluated.

sorry if I'm not terming this correctly.. but if I knew the terms I'd search ;)

this thread is bookmarked!
-Suzy

What I've noticed by experimenting (not by reading any specific information on the subject), is that when IE is unable to fully execute (eg: the last operation that was executed in the chain of operations, returned "false"):
(a=DOM.value)&&(b==true)
say "b" is not true, "a" will not be initialized. I don't know why, or if there is another reason involved in my situation, but it's what I've noticed. And no javascript error is logged in IE. Sometimes it's only a matter of syntax: "!(a==b)" is preferred over "(a!=b)" (or the reverse).

Overall, beyond this "problem", some expressions are constantly evaluated (when the mouse moves over the window), some only once. This is why you'll notice that in some scripts the coder has used a variable assignment (which forces regular evaluation).
My anti-jittering fix, for example, is constantly executed. Hence it needs to remove itself.
In another script I'm currently testing, I declare 4 functions inside an expression, and it appears to be exectuted only once (if I overwrite one of the function, it does not revert to the original version by miracle).

Expressions don't put load on server, only on the client machine.

If an expression generates a javascript error (syntax error), it is not evaluated more than once (on startup).
If an expression is a "constant", it is not executed more than once.
* {width: expression('10px');}
will screw your display, but will not overload the CPU (at least not on my computer).

[edited by: Achernar at 1:54 am (utc) on Mar. 8, 2008]

> conditional comments to target only IE6 >

I was saying that I agreed it might be better to place it in one file, one place, rather than hard-coding the IE6 downlevel fix into every webpage on the site with IE conditionals. And your slash/underbar hack for the css was the alternative in the one, single css file. But it might conceivably fail in IE8 or 9. You never know. One might otherwise count on the HEAD conditional, however, to be supported by future IE versions.

I notice that you didn't reply about various of these 'fixed' elements holding position with regard to one another when zooming in and out in IE. And I also found it very interesting that you were able to say that you could remove the fix and still have it work every time on scroll. Those css expressions DO fire a lot. It seems that you've overcome perhaps the practical objection to this if you can do so. You'll still have the 'purists' objections that you're 'behaving' in the css, and not 'styling'.

I notice that you didn't reply about various of these 'fixed' elements holding position with regard to one another when zooming in and out in IE.

Because it has nothing to do with my fix ;) , and I had to do some tests to see what is the problem. The problem could be with the expression you've used to fix the element. But in your situation I would only fix the main one, and position the others relative to it.

And I also found it very interesting that you were able to say that you could remove the fix and still have it work every time on scroll.

The fix is an expression, but it only set "true" css rules that, once in effect prevent the jittering. The other expression that keeps the element fixed is always running.

Those css expressions DO fire a lot. It seems that you've overcome perhaps the practical objection to this if you can do so. You'll still have the 'purists' objections that you're 'behaving' in the css, and not 'styling'.

I has been a long time since I last cared about purists. ;)
They are the ones that lose 4 days torturing themselves to come up with a "pure" CSS solution, and still have it break in some situations ; while a simple table layout would have taken 10min of work.
The worst are the ones that don't do this themselves, but encourage you to take this path.

If a single IE6-fix.css is enough to make a site work in IE, while keeping the page's HTML and CSS valid, it's perfect for me.
And as long as this fix is only slowing IE6 a little, It's not a problem. You see, I'm also testing sites on an old Celeron 450Mhz, and there is no usability problem. It's at least not slower than a site with a fixed background. So...

Check out this! Works like magic!

* html {
background-image: url(image.jpg);
}
* html #nav {
position: absolute; /* position fixed for IE6 */
top: expression(114+((e=document.documentElement.scrollTop)?e:document.body.scrollTop)+'px');
left: expression(35+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px');
}

I know, that's exactly what the script does. But it takes into account how your page is styled (background image and/or color, or not). You don't have to modify your pages.