I understand your personal need for sample code to examine, but this isn't an interactive tutorial, or, indeed, any kind of tutorial. It's a forum thread, which is why I linked to the tutorials. And one page of yours probably won't be sufficient, because, for each page, there might be some principles that don't apply to that page. And I'm not obligated to teach you. I offer resources to help you learn on your own.
Though no idea why that's important other than maybe making it run a few 1/1000ths of a nanosecond faster. Or preparing the browser for the file type.
Run-time efficiency is only one of many development concerns.
There's what I already stated, working towards a semantic web, following standards and not miring user agents in the past, requiring them to support outdated HTML usage. Turning this last point around, think how much easier web development would be if we didn't have to support IE 6. For some projects I've worked on, IE 6 has (no exaggeration) doubled the development time.
Then there's
Postel's Robustness Principle: "Be conservative in what you do; be liberal in what you accept from others." The page source is your product, so it should be conservative (that is, follow the standards). Tying this in to my earlier point, standards give you well defined behavior on the part of user-agents. Buck the standards, and there's no depending on what user-agents will do with your code. Imagine if there weren't C, C++ or Java standards. You'd have to port your source code if you wanted to change compilers because you couldn't depend on their behavior. As it stands, changing platforms already require you to port code.
What it comes down to is that you should always write to your audience. You don't write web pages for people. People, unless they're developers, don't care about source code. You write web pages for the programs that process them: browsers, spiders, mobile devices, accessibility devices and whatever else people can imagine.
Expanding on the point of "semantic web", remember that programs have no intelligence; they're can't even manage to be stupid. They can't deal with meaning, only structure. Structure can imply meaning, so by creating a well structured document, a program can deal with it as if the program could deal with some meaning. Since programs are your audience, write what they "know": structure.
As for examples of what to do, Descalzo already told you much of what needs to be fixed; the W3C validator will tell you more. The tutorials I linked to tell you even more. I'm not going to repeat the information (
laziness: the first great virtue of a programmer. "The quality that makes you go to great effort to reduce overall energy expenditure. [...], and document what you wrote so you don't have to answer so many questions about it.". See also the
DRY principle). If you have specific questions about fixing up your code, or something you don't understand, start a thread and you'll get help. Just make sure you explain what you expect and what you actually get, and include a minimal test case.
