Give help. Get help.

  • # March 3, 2013 at 12:44 am

    I’m trying to figure out how to accomplish this, if it’s even possible at all:

    I have a fixed header across all pages of my site, and I don’t want it to be part of the “scrollable” content below. Basically, I want it to interact as if it were a separate iframe, without being a separate iframe…

    Is this possible with CSS?

    # March 3, 2013 at 2:03 am


    Sorry…it’s just that simple.

    The scrollbar is not an HTML element…it’s a browser element.

    As far as I know, only Webkit will actually let you style it but you can’t change its fundamental functionality.

    # March 3, 2013 at 2:09 am

    It is possible. But it is darn ugly.

    # March 3, 2013 at 4:36 am

    Wow, that is sneaky…but you’re right…it’s really ugly.

    Also it’s a maintainability nightmare as far as block formatting context goes.

    # March 3, 2013 at 4:51 am

    It doesn’t work in Internet Explorer, even IE10 ignores the relative element’s boundaries or uses the wrong information to get it’s height. To make it work in IEs you’ll need a real table element in the markup as I do remember getting this to work cross-browser a few years ago. The result of having interest on doing “the impossible” :)

    You can use almost the same kind of table trick to make a site always have a min-height of 100% to fill the whole viewport, and it can be expanded on centering content to the middle of the screen, yet if content is too tall you’ll get a scroll bar – unlike with absolute or fixed positioning where you’d lose the top of the content.

    The conclusion for all of these table tricks: not recommended on any real site.

    # March 3, 2013 at 10:58 am

    I do wonder why this is even required…the viewer is, at best, not going to notice or care or, at worst will be confused.

    # March 3, 2013 at 12:36 pm

    @paulie_d, think of apps with fixed navigation. The scrollbar doesn’t overlap that, and why should it? It’s not being scrolled. The same should apply to web design, I think.

    # March 3, 2013 at 12:59 pm

    @CrocoDillon: ah yes, box-sizing is indeed a game changer these days. Can again do tricks that only worked in quirks mode previously :) Your example will need to add both -moz-box-sizing and -webkit-box-sizing to give it a better browser support, other than that I was surprised to see that even IE8 supports box-sizing: border-box; ( ) which makes it an actually usable feature on most sites.

    @patternicity: This is bit of a troublesome case for mobile devices. When implementing you probably want to also do a responsive design so you’ll only serve this kind of interface to high resolution devices that can afford the space.

    # March 3, 2013 at 2:19 pm

    >think of apps with fixed navigation.

    If I’m using a mobile app, I’m not using the scrollbar…I’m using my fingers.

    On a desktop all you will do is confuse users.

    # March 3, 2013 at 2:27 pm

    It doesn’t matter _how_ you’re scrolling, it matters _what_ you’re scrolling. Whether it’s with your finger or with a mouse or trackpad, part of the content is moving and part of it is fixed.

    Open up any application on your computer. Let’s take iTunes, for example. You probably have two scrollbars—one for the sidebar and one for the main content. Do either of these scrollbars extend into the control bar at the top? Of course not. They have no reason to. The control bar isn’t scrollable. The web, I am arguing, should function the same.

    # March 3, 2013 at 2:46 pm

    You can argue if you wish but the webpage has got along fine just as it is for many years now without feeling the need to start a new way of scrolling.

    Frankly the only reason I can think of for a scrollbar on mobile is for a visual representation of how far down the page I am.

    If you’re happy with it that’s fine though and in any case, I scroll with my mouse and not the scrollbar so perhaps the point is moot.

    # March 3, 2013 at 2:52 pm

    This isn’t a new way of scrolling at all. It’s an attempt to correct improper visual cues that shouldn’t exist today.

    And I dunno what OS you use, but on OS X and iOS the scrollbars are identical—invisible until hover or touch.

    # March 3, 2013 at 3:15 pm

    ( “Fixed Header solution”)

    As an example of this method in-practice, take a look at [Grooveshark]( “Grooveshark”).

    # March 4, 2013 at 11:16 am

    It might be historical reasons, actually. IE6 didn’t allow to combine top and bottom or left and right so it doesn’t easily come back to mind once you have the mindset of *it can’t be done* for so long :)

    So here is initial simplifying:

    But if one wants to be really clever and aim for the minimal amount of HTML:

    However I haven’t tested browser compatibility to see how many browsers actually allow to set position: absolute; on body element.


    1. All non-IE desktop browsers seem to be OK!
    2. Internet Explorer 8+ is OK!
    3. Internet Explorer 7 is almost OK! (displays extra disabled vertical scrollbar)
    4. IE6 doesn’t even support position: fixed; so no luck to be expected. Didn’t allow the position: absolute; on body either.

    # April 4, 2016 at 4:13 pm

    Thanks for pointing the solution @Merri. I’ve been looking for this and it works almost perfect…
    The only thing is that in mobile browsers you can’t reload a page using scroll up, at least in Chrome… it could be an important feature for some websites :/
    I think that ‘html { overflow:hidden; }’ is the culprit.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic.