Treehouse: Grow your CSS skills. Land your dream job.

Fixed Header that isn’t overlapped by scrollbar?

  • # 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 7:31 am

    I have the same interest on doing the impossible, so I had to try to make this work without tables. The hardest part was subtracting a fixed size header from a fluid size window, wish I could just do `height: 100% – 80px;` :)

    # 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 3, 2013 at 4:13 pm

    Why didn’t I think of that…

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

You must be logged in to reply to this topic.