XHTML 1.1 Challenge - 100% Height DIV Elements!
Ok, so here is something I've been trying to do. I've never been able to not figure something like this out, but alas, I concede defeat. Here is what I'm trying to do...
Take a web page. Now split it in half. On the left half, you have a solid colour. On the right half, you have a different solid colour. Now, you want to put a lot of text on either side. In essence, each side is its own page. The problem is that it doesn't work when a scrollbar appears; that is, the colours stop at the bottom of the window, so when you scroll down, they don't continue.
Anyone get this, or do I need to show some example code?
Take a web page. Now split it in half. On the left half, you have a solid colour. On the right half, you have a different solid colour. Now, you want to put a lot of text on either side. In essence, each side is its own page. The problem is that it doesn't work when a scrollbar appears; that is, the colours stop at the bottom of the window, so when you scroll down, they don't continue.
Anyone get this, or do I need to show some example code?
Comments
First, put all three div's in a shell
then
make the background of the shell a picture that will look like three different colors.
OR
make the background of the shell the same color of the two columns (if they do not extend), so it will look like they go all the way down.
http://turborodent.com/extant/
Here on the front end, It renders fine. The CSS isn't fine tuned yet, colours and borders and all, because I'm still tuning the actual structures. Now, if you shrink the browser window on the front end, to the point where you need to scroll, then expand the window, you will see that the blue actually gets cropped as well.
Now, for the bigger rendering bug, which I just cannot figure out, try this address...
http://www.turborodent.com/extant/archives/000005.html
Scroll down. Yeah. What's up with that?
I've been changing parts of the CSS all day, but I'll stop now so that you guys can take a gander. I just want those two main DIVs, the black and the blue, to be 100% of the html body's height, not 100% of the browser window's height... which seems to be happening because it's getting cropped
http://www.alistapart.com/articles/fauxcolumns/
More fundamental problems are the use of XHTML 1.1, you want to be using XHTML 1.0 (and in fact your doctype claims you are). And the first thing you should do when you're having problems with HTML + CSS is to validate both the (X)HTML and the CSS file. In fact you should do this constantly even if you aren't having problems.
Originally posted by stupider...likeafox
You have to cheat:
http://www.alistapart.com/articles/fauxcolumns/
More fundamental problems are the use of XHTML 1.1, you want to be using XHTML 1.0 (and in fact your doctype claims you are). And the first thing you should do when you're having problems with HTML + CSS is to validate both the (X)HTML and the CSS file. In fact you should do this constantly even if you aren't having problems.
His solution was already considered a while ago when I was only having the one issue with the front end. Click on the second link I provided, and explain to me what exactly is happening there.
I'm writing to XHTML 1.1, not 1.0. I'm using a CMS on the site that munges my code, only because I haven't finished setting up all of its templates. On my front end, only two errors show up when validating, and those are the onMouseOver's embedded in an element that I just haven't bothered taking out yet. I write in BBEdit, and I validate my documents every time I build another major portion of the codebase.
So this guy's solution doesn't really help because of the problems encountered in my second link. It especially doesn't help when I'm thinking about the bigger picture, and how I planned on manipulating the DIV elements more dynamically, but I'm not really going into that here right now, and I really don't want to think about the JS I'll be writing for that
Your pages include the following line:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
which basically says "this document is XHTML 1.0".
And I get validation errors on both your links, moreso the latter:
http://validator.w3.org/check?uri=ht...tomatically%29
Debugging HTML + CSS that doesn't validate is usually lunacy.
The comments on the article present a few alternative methods, some of which are more fluid.
mod edit: truncated doctype in code to remove horizontal scrolling.
Annnnnnyhow.
There, the front end renders without error. And it still has the same problem. Unsurprising if you actually looked at what the errors were in the code that kept it from validating properly.
The second page, as I explained before, has what is it, five error messages that were caused from the CMS closing the <p> element after a <blockquote>.
It's not really lunacy trying debug this stuff if you know what your errors are. And I know these errors aren't affecting what the real problem on the site is. I mean, hell, even if I copy from "View Source" and paste into BBEdit and preview in Safari (Something I can't really do working from my templates because, as I said, the CMS actually adds all of the content) the same problem exists. Which isn't surprising, because I know what the errors are. I'd fix them if I knew exactly how to configure the CMS to do it right now, but I don't. So I'll fix the layout issues, and then fix the CMS.
Anyhow, his other recommendations, as I said, don't really solve the problem for me either. It's a good article, but it only covered solutions I had already thought about a while ago.
*sigh*
Originally posted by LoCash
It's not really lunacy trying debug this stuff if you know what your errors are. And I know these errors aren't affecting what the real problem on the site is.
That's a really bad habit you're getting yourself into. The interaction between Browsers, HTML & CSS is more complex than you think and logic often has little to do with it so the first step should always be to validate.
It *will* bite you on the ass if don't.
The second page's errors came from new content I had rotated into the CMS. I was having the same problems before the second page's code didn't validate.
It's not like I make a habit of intentionally deploying code that doesn't validate. I know what I'm writing, I know to an acceptable extent how what I'm writing is interpreted. I also know it all well enough to know that the TWO errors that showed up when validating the front end's code weren't the cause of my problem, and I had bigger things to focus on.
I appreciate your concern, but it's not like I published something with 40 errors that were all over the place. It's totally controlled, I knew what was happening, and they were placed farther back in the queue to clean up before deployment.
So yeah, working with stuff that doesn't validate will bite you in the ass... if you don't know what you're doing. I'd already verified that the errors were causing no harm to the rendering issues, so rather than figure out how to get the bloody CMS to correct its mistakes, I ignored it.
Originally posted by LoCash
So yeah, working with stuff that doesn't validate will bite you in the ass... if you don't know what you're doing. I'd already verified that the errors were causing no harm to the rendering issues, so rather than figure out how to get the bloody CMS to correct its mistakes, I ignored it.
I'm really stressing this now for anyone else reading this, as I think you've made up your mind, but *do not* let errors remain in HTML + CSS, or any kind of programming language because you 'know' that they aren't affecting what you're doing because the simple fact is, especially with CSS, you don't. It doesn't matter how good you are, it *will* bite you and it *will* be a pointless waste of your time.
There is often *no logic* in CSS problems. They can be your own fault or they can be renderer bugs. CSS is incredibly complicated and there are parts of the CSS spec that even the guys who are writing different browsers disagree on. A single character change can make your page render through a totally different code path within even a single browser.
You removed the non-validating error (problem A) and it didn't fix your problem so you put it back. But what if the problem was a combination of problem A and problem B? You fix B and nothing happens, then later you fix the validation error and it 'magically' fixes the original problem when it didn't earlier. You can't have verified that it was unrelated unless you had fixed the problem.
But this particular case isn't the point. The point is it's crazy to ask people for help with CSS when your document doesn't validate as *the* first thing they will do is try to validate it. And it's not a good idea to allow easy to fix 'unrelated' errors to remain while you debug.