Page shows normally in IE7, Firefox, Opera but invisible in IE6

Open all your browsers (all 5 or so of them) and open a text editor. Notepad is fine but has issues with UTF-8 if you're using that (and UTF-8 is great). Notepad++ doesn't have the problem I guess. There are lots of free ones out there who do syntax highlighting, auto-completion, ftp, all that stuff people seem to like.

Yes, ditch dreambeaver until you know what you're doing and can read and write code fine. Some people like DW's extras like its own FTP and whatever other junk it does, but do not use it for the coding itself. In any case, DW needs a tight rein and that's only possible when you know how to code first. And never, never bother with DesignView. The browsers are the only ones you care about as far as rendering.

Every time you make a change somewhere, refresh all your browsers. For small things, you can just check in one until you're done with little tweaks, then check in everyone again (for seeing what certain code does, I would look in at least FF and IE).

 

Dreamweaver is a steaming pile of overpriced crap - It can't handle 'real code', vomits up a mix of 1988 javascript and 2001 HTML and claims that it's a website, and the only thing it can teach you about coding a site is how NOT to do it. My advice to ANYONE using dreamweaver is to deinstall it to recover the disk space, shred the manuals, burn the packaging, and use the CD for microwave art. If Dreamweaver is a professional grade tool, I'm inline to be the next Mahatma.

You were really close on the design tools I use. My tool list is:

Paint Shop Pro (it has better format encoding than any other paint proggy)
Crimson Editor (simple notepad replacement - I used to use win32pad)
The Brain.

The most important of those is "the brain".

Stomme Poes said the exact process - open up ALL of the browsers and test in them... One of the BIGGEST mistakes people make is coding the entire site to ONE browser/browser engine (like dreamweavers preview panel) before testing in other browsers. This just makes finding what's actually wrong harder because you don't know if the part that's misrendering is at fault, or something next to it, or something completely unrelated elsewhere is somehow causing a misrender.

The HTML should be fairly simple if you know a few 'tricks' you are going to use ahead of time - on the whole apart from column wrappers and image-replacement techniques, you should write your HTML with NO concern for what the final appearance will be. Mark what things are, and if you are adding a div, class or anything else ask yourself "Do I need this class" or "do I need this container?" - too often you see people wrapping DIV's around UL that serve no purpose. Notice in the 'header' part of mine there's no wrapping DIVs - it's just H1, UL#topMenu, UL#mainMenu... because that's all it needs.

Only once you have ALL your markup in place with NO presentational tags or attributes apart from some common wrappers (#container, #contentWrapper, #content, #sideBar, #footer), do you apply your styling and layout via CSS.

When working in the CSS work section by section top down, and KEEP checking in browsers as you go. Try to avoid adding extra container div's to the HTML as much as possible (though sometimes with dynamic height/width borders there's little choice). If you work top down, one section at a time, as problems crop up you can nab them as they occur, instead of trying to dig through a "completed" site trying to figure out what or even where something went awry. It also makes it easier to maintain later on if you keep your CSS in the order it appears on the page as much as possible - Separating out "fonts and colors" from layout as some people do just confuses the matter.

The biggest asset a good web developer can have though, is organization skills and good coding habits. Proper indenting (learn to use the tab key, as well as how a selected section in most editors will tab in ALL lines, or de-tab on shift-tab), property PER LINE (seriously, how the **** do people work with that single line jumble), meaningful comments (and not wasting time commenting the obvious) all go a long ways towards not only avoiding problems in the first place, but making it easier when you ask others for help AND on the next poor shlub who works with the code of your site.

I always point people new to coding at this article - while his code has a few #DDD moments, what he says about clear, comprehensable code and comments is spot on. (I'm particularly fond of the "Oh? NOW We're done?" part)
http://www.ibm.com/developerworks/linux/library/l-clear-code/

 

I remember sending that link to a colleague of mine last year, but he still has this love affair with
variables_without_caseRules_that_R-verylong-andTakeDays_2_read

div id's with names like #PersonensgegevensRechtsbijstandMetCascodekkingRubriek_1 are teh lose.