Position: Fixed and IE6

Paul Trautwein wrote:

I did find an obscure reference (http://www.w3.org/Style/CSS/) commented
in the source code of one of the styles used, that mentions problems with
"fixed" positions in IE6, but no solution that I was able to interpret.

Problems? MSIE doesn't support it at all. It treats it as position: static.

JavaScript hack: http://www.mark.ac/help/sticky.html

Thank you. This is exactly the kind of thing I was looking for.

Paul Trautwein wrote:

I did find an obscure reference (http://www.w3.org/Style/CSS/) commented
in the source code of one of the styles used, that mentions problems with
"fixed" positions in IE6, but no solution that I was able to interpret.

Problems? MSIE doesn't support it at all. It treats it as position: static.

JavaScript hack: http://www.mark.ac/help/sticky.html

Thank you. This is exactly the kind of thing I was looking for.

David Dorward / 2003-09-10 20:11:

Paul Trautwein wrote:

I did find an obscure reference (http://www.w3.org/Style/CSS/) commented
in the source code of one of the styles used, that mentions problems with
"fixed" positions in IE6, but no solution that I was able to interpret.

Problems? MSIE doesn't support it at all. It treats it as position: static.

The problem isn't that MSIE wouldn't support 'fixed' value but that
the support is buggy and it interprets that as 'static' as you
mention. If it didn't have support, the correct behavior would be to
ignore the rule. Think following example:

..foobar {
position: absolute;
position: fixed;
}

Any correctly implemented browser that supports either 'absolute' or
'fixed' would result in more or less acceptable rendering. If the
browser didn't support 'fixed' the element would still be correctly
positioned ('absolute') but it simply wouldn't "float" above the
content while scrolling the page. However, MSIE happily "supports"
the 'fixed' value and that support is so buggy it seems that the
result is 'static'. The element will be positioned to entirely
different place.

Easy fix:

..foobar { position: absolute; }
html > body .foobar { position: fixed; }

MSIE won't follow the rules on the second line because its support
for CSS2 selectors is lacking.

--
Mikko

In article <BB****************@paultrautwein.com>, Paul Trautwein wrote:

I'm trying to get an image to float in a window despite scrolling.

I've gotten it to work on my Mac using IE 5.2, Netscape, and Safari, but it
goes wonky when I test it on a PC. (testing with IE only at the moment.)
Positioning is wrong, and it doesn't float at all.

Here's a test page: http://www.bdiusa.com/mirrors/test.html

I've tested the code using the CSS Validator on the W3 site - and it said
it's okay.

I did find an obscure reference (http://www.w3.org/Style/CSS/) commented in
the source code of one of the styles used, that mentions problems with
"fixed" positions in IE6, but no solution that I was able to interpret.

Hi. There is a workaround.

My CV at
http://www.turnip.clara.co.uk/jvaughan_cv_sysadmin.html
uses one, thanks to CSS borrowed from ricfink's post at

http://www.webmasterworld.com/forum83/560-3-15.htm

As you say Windows IE5/IE6 doesnt support position fixed properly, hence
the ugly workaround.

Hope this helps you

Jon

Lauri Raittila wrote:

In article <wC08b.414971$YN5.279720@sccrnsc01>, Brian wrote:

Mikko Rantalainen wrote:

.foobar { position: absolute; }
html > body .foobar { position: fixed; }

MSIE won't follow the rules on the second line because
its support for CSS2 selectors is lacking.

I think there must be no spaces in the child selector.
< http://w3development.de/css/hide_css...rowsers/child/ >

Thus, the op wants

html>body .foobar {position: fixed }

Afaik makes no difference, at least not on WinIEs I have tried.

Just tested this on MSIE 5.0/Win. It *does* make a difference. To
hide a child selector, this must be no spaces, e.g.
body>h1

and not
body > h1

--
Brian
follow the directions in my address to email me

In article <IZ48b.416626$YN5.280101@sccrnsc01>, Brian wrote:

Lauri Raittila wrote:

In article <wC08b.414971$YN5.279720@sccrnsc01>, Brian wrote:

Mikko Rantalainen wrote:

.foobar { position: absolute; }
html > body .foobar { position: fixed; }

MSIE won't follow the rules on the second line because
its support for CSS2 selectors is lacking.

I think there must be no spaces in the child selector.
< http://w3development.de/css/hide_css...rowsers/child/ >

Thus, the op wants

html>body .foobar {position: fixed }
Afaik makes no difference, at least not on WinIEs I have tried.

At least IE5.5 and IE6 IIRC
Just tested this on MSIE 5.0/Win. It *does* make a difference. To
hide a child selector, this must be no spaces, e.g.
body>h1

and not
body > h1

Does that mean that child selector _works_ with spaces in IE5.0? That
would be surprising.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Brian wrote:

Lauri Raittila wrote:

Does that mean that child selector _works_ with spaces in IE5.0?
That would be surprising.

I just retested, using MSIE 5.0/Win2k. The following declaration

div > h1 {border: thin solid blue }

*does* produce a blue border.

OK. Could you test which ones of these it makes blue:

<div>
<h1>test1</h1>
</div>

<div>
<blockquote>
<h1>test2</h1>
</blockquote>
</div>

<h1>test3</h1>

Only test1 should be blue.

I'd be interested to know if MSIE5 simply ignores everything before h1
(that is up to ">") or if it simply ignores the ">". I don't think it
supports child selectors correctly.

--
Mikko

Brian wrote:

Mikko Rantalainen wrote:

<div>
<blockquote>
<h1>test2</h1>
</blockquote>
</div>

div> h1 test 1 and 2 have border; 3 does not (correct behavior)

Beg your pardon? Test 2 should *not* have a border: it is not a direct
child of a div. The rule you're thinking of goes along the lines of
'div h1'.

Owen Jacobson wrote:

Brian wrote:

<div>
<blockquote>
<h1>test2</h1>
</blockquote>
</div>

div> h1 test 1 and 2 have border; 3 does not (correct behavior)

Beg your pardon? Test 2 should *not* have a border: it is not a direct
child of a div. The rule you're thinking of goes along the lines of
'div h1'.

A thousand pardons I beg of you. Only test 1 should have had a border
in all the tests. In no test did MSIE 5.0/Win2k get it right.

--
Brian
follow the directions in my address to email me