Tagsoup · Web Development

position:fixed for Internet Explorer

This is a hack to emulate the CSS 2 positioning scheme position:fixed for Windows Internet Explorer without active scripting (including dynamic properties, behaviors and whatnot).

Status quo (2006-09-26): Internet Explorer 7 applies its numerous CSS changes – including support for fixed positioning – only in ‘standards-compliant mode’. Both methods described below should still be ‘safe’ to use (albeit for different reasons). More info about new possibilities and consequences in terms of doctype-sniffing will be added soon.

IE >= 5

The reason that the initial approach does not work in versions prior to 6 is lacking CSS support for the root element. There is, however, a trivial workaround: create a dummy element that serves as the document body and move the relevant properties one node down.

body
  {
  overflow: hidden;
  }
div.content
  {
  height: 100%;
  overflow: auto;
  }

Absolutely positioned elements outside of div.content will be fixed in respect to the viewport, absolutely positioned elements inside of div.content will behave normally. This works in version 5.0 and higher of IE on windows and is the most stable solution available.

This makes it mandatory to trigger quirks mode for IE >= 6, e.g. by inserting a comment (accurately: comment declaration; see also: other prolog) before the document type declaration. It could be avoided with some additional code overhead, with no advantage but a couple of general bonus bugs in return.

Complete cruft-free demos:

  1. fixed left bar
  2. fixed top bar
  3. fixed right bar
  4. fixed bottom bar
  5. fixed top and left bar

Rationale

No user agent but Windows Internet Explorer must be exposed to any of the CSS rules relevant to the hack; I strongly recommend using conditional comments instead of exploiting parsing bugs to accomplish that.

Some older user agents that support position:fixed cannot handle it very well, e.g. IE 5/Mac. For maximum bugwards compatibility you should consider to @import the offending rule sets and wrap them in an @media screen block – the latter also serves an important semantic function, and the media type screen should be explicitly specified for the IE/Windows style sheet as well:

<style type='text/css'>@import 'all.css';</style>
<!--[if IE]>
<link
 href='ie_win.css'
 type='text/css'
 media='screen'>
<![endif]-->

Using @import in a style element to basically link a style sheet is somewhat ugly but compact; blindly spawning http connections with multiple linked, imported and conditional style sheets is not a good idea, especially since user agents commonly request all files associated with a document, regardless of whether or not they actually support the corresponding MIME or media types.

IE >= 6

Internet Explorer >= 6 supports CSS for the root element in ‘standards-compliant mode’. Moving the scroll mechanism from the root element to the document body will cause absolutely positioned descendants of the body element to be fixed in respect to the viewport.

@media screen
  {
  * html
    {
    overflow-y: hidden;
    }
  * html body
    {
    height: 100%;
    overflow: auto;
    }
  }

There are a couple of disadvantages involved:

On the upside,

Complete cruft-free demo:

  1. fixed box for IE 6

Traceroute

On 2002-02-05 someone dumped a query regarding fixed document content in the Dutch news group nl.internet.www.ontwerp. The offered javascript solution by the local wizard was naturally bulletproof as usual but looked quite hairy to me as a replacement for one unsupported CSS property. In return, I came up with a simple overnight CSS-only mock-up for IE 6 (Note: the referenced URI became a victim of link rot, but – for the better or worse – Google kindly returns a mirror by Rijk van Geijtenbeek).

A short time later, this became quite popular in the course of an mxvision feature. Since the interest flux did not drop, I added some improvements in terms of stability, and finally support for IE 5 – but not before having witnessed that the enemy does not sleep either (you may take that literally, as this helpful answer on a request for clues reveals – and it should sufficiently explain what a hack attack really is :-).

Related

Acknowledgements

Thanks for contributions, head-ups and inspiration to ‘Warden Dave’, Tim Rivera, Richard Hulse, Marcin Sokolowski, Barbara de Zoete and especially everybody I forgot to mention.


info@tagsoup.com 2008 Tagsoup