If the parent has a border, or padding or some text content then the margin would not collapse. It's only when there is nothing between them that it collapses. (The same would hold true for bottom margins but side margins don't collapse.)
Ok, sucks, Paul's not going to be around for a while, but when I read that I was wondering... if using :before and adding content (like a space) would "count".
It would have to be on #container, since :before basically creates a first-child of #container.
Not that it would be an actual solution (as IE6 and 7 don't know :before) but just curious. Guess I'll try it myself.
Don't worry, as gruff and grumpy as he sounds, he really only ever cares about code (even when he hates it)... trust me, his comments are never really directed at YOU. (You only know that after you've seen him on a forum for a while.) And like all of our loud-mouth critisisms, it's up to you to decide which of it you'll take on board and which you'll discard. What every developer does.
1.) Ignore latest technologies and stick with HTML4.01 and CSS2.1 and be stuck in the dark but reccommended ages.
While I'm not as fanatically against some of the newer stuff as Crusty (because I don't mind a degraded, not-so-pretty user experience for retarded/older browsers so long as the site still functions), he has a very good point.
I disagree about using the short doctype... it's true it works back to IE5 and Mozilla back when it had a dinosaur head for an icon, and what Crusty is talking about is the validator... BUT you can tell the validator to assume an HTML4.01 Strict doctype, and you SHOULD do this, for the reasons he mentioned: get real decent feedback from the validator.
The doctype only exists for two reasons anyway: tell the validators which rules you state you are playing by, and to keep browsers using their "standards mode" (only because they use "doctype switching" to decide which rendering mode to use).
I have no issue using <!doctype html>, but I would never validate with it, because I'm still writing HTML4.01 strict as far as the code goes. In fact I also tell it to test as XHTML1.0 Strict, since there it will complain about my quotes, uppercase (not that that's ever an issue), and missing </p> and </li> tags.
With CSS3, if your client/employer insists on having FF2 and IE6 look exactly the same as IE9 and FF4, then using half-working newer technologies and then a fat layer of scripting on top to do that is a slower, more bloated way to do it. I would take Crusty's old-fashioned image technique instead without further thought (option #1).
So when to use the CSS3 stuff (which by the way is NOT entirely draft, as you've noticed... modules instead of the whole spec get approved, not that I expect "candidate recommendation" to ever appear on any of them... not at least until I'm 40 or something)? Use it when you have simple code working for everyone, and then want to use the newer CSS properties to visually enhance the sites for the browsers who do understand... and I don't mind using the experimental prefix versions, since whenever someone releases a newer version that works with the default, it's one command in my text editor to remove the prefix. Also, prefixes allow you to NOT include any browser whose implementation isn't the same as the others, which is why prefixes are good. We don't have to hack to prevent a browser's crappy implementation from showing up, and ideally they'd only work with the default property (like border-radius) AFTER it actually works properly in their browser. So, your option #2.
I'd say option #1 is when you're required to have everyone the same, and are catering to absolutely "everyone".
Option #2 is when you have leeway to let older browsers get a degraded-but-functional experience, but still must cater to "everyone".
Option #3 seems to only be ok for fancy web designers who want to show off how on-top of the latest fad they are to other nerds who only surf with the latest technology (and aren't using NoScript, and aren't using a screen reader... which are still hiccupping on the latest HTML5 stuff). I know of a site based in Amsterdam which has gone entirely to HTML5 (with a ridiculous amount of scripting and hacks to get it all working in some IE's and older browsers) which, because their audience isn't necessarily only nerds, I would not have done. The pages are large and heavy.
See this page: http://www.nczonline.net/blog/2011/03/22/using-html5-semantic-elements-today/ and especially, read the comments.
I KNOW deathshadow60 HATES extra packages like jquery and selectivzr but they are available to speed up the coding and development times (as far as i know anyway).
They speed up YOUR time but they add lots of code you aren't using to the BROWSER (which then might affect the user... depending on their browser and their internet access). Depending on what all you're loading, that's more bandwidth for users. Some users never notice, sitting on their fiber optic or T1 connection. Some people have crappy bandwidth and have to pay for it. Which group are you serving? If your site is meant "for everyone" then you're serving the second group too.
I really need to figure out what route I am taking in regards to development. Recently you (deathshadow) have posted long posts about 2 of my in progress sites about how they SHOULD be coded. I am in no way stating that you are wrong or incorrect or do not appreciate your advice or comments but both times, it has put me down and made me feel like I should just not be doing this at all. I know I shouldn;t feel like that as I know I am just being given advice but different people keep telling me different things from all different angles and It's extremely confusing deciding what to do.
It's both good and bad to get conflicting advice. It's bad if you're a n00b because you don't know who's right (for many things, there isn't one right anyway). It's good if you're learning though because you get all the other viewpoints.
Some people say stick to the old and reccommended stuff, some people say if a browser supports it then use it, some people say use anything, some people say support ALL browsers, some people say don;t bother, some people say this and others say that! This is what is confusing me.
Because once people have gotten over their n00b hump, they decide "I'm going to code like THIS for THESE browsers". Then they give you advice based on their decisions. A good dev is constantly re-evaluating their techniques and what they're coding for. In your case, it'll probably be best decided by "who are you coding for?" (meaning, visitors).
Generally when Crusty does a rewrite, it's pretty good and other experienced developers would consider it a good rewrite. But you don't have to use it. When I was a n00b, I learned a LOT from watching him (and others) rewrite other people's code, esp when there was commentary explaining Why this and Why that. Did I do everything that way? No. I take his rewrites as learning tools.
And if it makes you feel better, he rewrites good code other experienced devs have written too, maybe mostly because he disagrees with their coding style or particular techniques they've used. Meh. The more you code, they more you decide what you'll do and what you won't. Crusty supports IE5. Most developers don't. Some developers like optimisers and whitespace scrubbers. Some don't.
Anyway, this is a forum, not a boss. Learn what you can from it, and ultimately you'll decide what you take away from it. Don't feel like it must all be over your head and you must suck so should quit. The people who suck and should quit are the ones who continue writing garbage and are unwilling to learn from others. You came here with a question, and you didn't just want to know how to fix one particular bug, but you were willing to go into discussion about your code in general. That's good. That means you have in you what you need to be a good developer.