Okay, what I'll do is copy over basically what I said in a mail earlier. I was PMed asking if the advice given here was any good... but by then it had kinda gone quite a ways, so I was hesitant to answer here. But someone on the SitePoint staff mentioned other people find threads via google and search and whatnot, and that it probably would be bad to just leave it without mentioning what's going on.

I used a premade template from the internet and css, which I changed then manually, I liked the images for the menubars and headers and so on, and the lay-out, so I used that as an example.
That probably expains a lot of it. You'd get the same problems whether it was a template from some site, or a template from any of the popular WYSIWYGs like DreamWeaver or iWeb. Basically: templates always have horrible code, and they are meant for users with little/no knowledge to have something to start with; in order to be flexible for anything weird a user may want, they usually have too much code so that users have more choice.

The better you get in writing your own HTML/CSS from scratch, the better your markup gets and/or the better you can tweak templates later on.

I do know it is necessary to change some drastic things in my designing for to next sites that are to come. I currently got 3 little companies wanting me to make a site for them.
This is good; depending on how much time you have for them, you can learn on these. I learned both by starting out doing exercises from books and seeing code on forums, but also by practicing what I learned on sites for our company. So of course the stuff I did in my first two years makes me cringe. It's supposed to. As one member here likes to say, if code you wrote two years ago doesn't make you vomit, you've stopped learning : )

I do think that the site(like it is now) is running and looks good, for simple users (in most browsers as I noticed). Therefore I think rewriting the whole thing is a bit harsh.
As I said, depending on your situation it may not be worth it. However in a few years you'll very likely agree with me about rewriting : )

Anyway, here goes my (modified) mail:
First, Maxx's post:
the javascript he posts, is clearly 15 years old or maybe more:
Code:
if (document.getElementById) { // DOM3 = IE5, NS6
First the code checks for the w3c way to get elements, which today all browsers in popular use can do.
Big clue there when it's talking about IE5 and Netscape Navigator 6.
The code then tests for document.layers (some old Nutscrape thing), and finally the ancient document.all (very old IE and also old Opera).

While some libraries still start out with a check for document.all or not, it's mostly to see if the code is dealing with some of IE's other problems which do persist up to IE8 (like, IE uses attachEvent instead of addEventLoader).
However changing someone's style from display: none to display: block works everywhere with just the first (w3c) version, so this code he's using he must have plucked out of the Wayback Machine: it's only testing for ancient browsers simply to grab an element.

Quote Originally Posted by Maxx
I want to expand the text (in <p>-tag) by clicking on header 1. When I click on header 2, I want to collapse text of header 1 and expand header 2 text.
For accessibility reasons, requiring that users have a mouse and who can see is also kinda shortsighted (and in some countries illegal, but currently not for some Mom and Pop Interior shop in the Netherlands (edit or Belgium)). These things need to work with keyboard too, meaning you need a focusable element somewhere. Usually we fix this by having an anchor inside the header who doesn't go anywhere.

----------------------

<a href="#first" onClick="shoh('first');">
Inline Javascript... think of a nun... no, think of the Queen of England, frowning furiously and saying "hmph! We are NOT amused, young man." And disappointment flowing from her in waves. Instead, in today's code we let Javascript find the elements it needs and do whatever it needs to do (by giving the anchors id's or classes or something), so JS doesn't pollute our fine markup.

The reply:
Code:
var me_obj = document.getElementById(me_id);
var me_height = parseInt(me_obj.style.height);
me_height = me_height + 5;
me_obj.style.height = me_height + "px";
I notice that code repeats this for every single function. Usually that's a big sign that you can write it much more compact. Don't Repeat Yourself, it's called. It's not that it won't work, it's just unweildy to maintain. In later posts of code, the variables were set just once. That's what you strive for.

Also, as Maxx noted, text isn't the same on every browser or every machine... and people with eyes over age 40 may need to start enlarging it. Which browsers do gladly. Setting height in pixels will work in some browsers some of the time but breaks easily. Another solution would be to, for example, have the text absolutley positioned offscreen and then just set it back to position:static when it's "open". That way, the text will take up whatever room it needs.

Reply had:
Code:
<form id="form1" runat="server">
Runat="server" is a sign of ASP satan himself. Run screaming. Now.

Even if it's used at work. Run. Now. Save your soul.

(also, wrapping entire pages in forms is also a bad idea anyway)

Code:
<font size="6">Heading 3</font>
Font tags pretending to be headers will never rock as hard and awesomely as real header tags. Don't fear <h3>Heading 3</h3>, it does lots of stuff you may not realise (like help the blind navigate a page when using a screen reader or Refreshable Braille Display) and sets a document structure.

This was all a bit of a 90's flashback for me, you see. It's not that it all doesn't mostly kinda work— browsers don't quit supporting stuff when it's deprecated in the spec, mainly to keep those pages who really were written in the 90's available— but they aren't good practices and even if you see them in the wild, they're endagered species who should not be saved from extinction.

Quote Originally Posted by Maxx
When i make my screen smaller, on IE, my site looks like it should be on half the screen, just some scrolling needed to be done, on firefox I'm getting an oversized header, and my content with the table with photo and text in it, is floating somewhere in the topleftcorner..
While a Javascript-looking-at-window-size may help, the problem is due 100% to his already broken layout with the table and whatnot. Fixing it the "right" way would entail a rewrite, which Maxx may not be interested in or may have a deadline or something. I can suggest he's wrong, but that does sound kinda hollow without offering a solution, or with a (totally rewritten) solution, it sounds kind of elitist. Not that there's anything wrong with elites, I'm happily a web standards elitist nazi pig myself, but sometimes it doesn't help people, depending on their situation.
*edit with the downloaded text and css files, I can't see the header so don't know if it's still too large in Firefox, but really want to know why a table for the big section in the middle... what is it supposed to do? There may be a better element we can use. But we definitely don't need JS to fix it. Right now the middle part isn't in the top right corner in my Firefox though, it's in the middle of the page, but doesn't fit when browser is smaller.

Finally, with his overflow-scrollbar problem... if he has a set width on those elements, instead of setting them to overflow: scroll (which creates scrollbars both directions), he could just take the overflow: hidden being set and let it go back to the default, overflow: visible. Or, the original overflow: hidden can be set separately on x and y axes... called overflow-x and overflow-y. If the width of the p doesn't exceed whatever width he's set on the box holding the p (the div) he shouldn't get a horizontal scrollbar, only a vertical one (though I agree, they look pretty ugly anyway).

If it were my page I'd redo it and use some other method than setting height to hide/show those p's... as I said earlier, using position: absolute and moving it off the screen removes the p's from the document flow, so no space taken up by them... and putting them back in the flow by setting them to position: static means no worrying about heights at all.

If you'd like to see an example of something similar I had to do (and it's not great, and the Javascript is... convoluted due to n00bness), http://stommepoes.nl/Homeselling/SHL/shlinks.html and today, if I were to do it again... I would have display: none'd the stuff. I normally don't, because normally I want screen reader users to be able to get to it... and screen readers *usually* take display: none seriously: the element is not on the page, so it doesn't get read out. However here, some browsers would tab through the sub-anchors who were offscreen (hidden) while Opera for example didn't. Opera's way was best. I should have display: none'd it to prevent that. With Javascript setting it, instead of CSS, it would have been safe, and with the anchors being created in the headers, it's naturally keyboard focusable, etc.
Turn Javascript off, and you get the default: all the information shows. This is accessible and JS is just making it nice.


End mail.
In other words: knowing the best way to do layouts with CSS will help make a page act mostly the same cross-browser. Absolutely positioning stuff everywhere is probably the most-common way people get trouble when screens are different sizes (I can see you did not fall into that trap), though it's not the only problem people can run into.

I only have your html and style.css to work from, but I can go through some things I would do differently. Tho without the images or javascript I'm not seeing what you're seeing.