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...
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.
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; :)
@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.
@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; ( http://caniuse.com/#search=box-sizing ) 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.
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.
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.
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 :)
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?
No.
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.
It is possible. But it is darn ugly.
http://cdpn.io/xGujE
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.
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.
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;:)http://codepen.io/CrocoDillon/pen/caksz
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.
@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.
@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; ( http://caniuse.com/#search=box-sizing ) 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.
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.
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.
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.
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.
I found a simple solution.
As an example of this method in-practice, take a look at Grooveshark.
Why didn't I think of that...
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: http://codepen.io/Merri/pen/ebKtf
But if one wants to be really clever and aim for the minimal amount of HTML: http://codepen.io/Merri/pen/kEpwI
However I haven't tested browser compatibility to see how many browsers actually allow to set position: absolute; on body element.
Update!
Good thinking at styling the body like that :)