• Explain which div you’re closing

WTF? Syntaxhighlighting, ordentliche Einrückung oder Codefolding reichen.

• Use a CSS reset

Hell, no! Auch wenn Eric Meyer das sagt, damit halst man sich unnötig Arbeit auf.

• Don’t use @import

Dem atimme ich zu - aber die genannte alternative ist mindestens genauso dämlich, wenn dann gleich Serverseitig zusammenbauen und komprimieren.

• “Smush” your images

Warum nicht-

• Don’t mix CSS with HTML

Ja.

• Don’t mix Javascript with HTML

Ja.

• Use conditional comments

Das kommt auf die Dimension an - bei einer Hand voll korrekturen sind Hacks (aber die sauberen) sicher ok, bei umfangreichen korrekturen sind Conditional Comments wesentlich einfacher handhabbar.

• Place Javascript file at the bottom

Wozu? Wie der Client die das Dokument bearbeitet bleibt ihm überlassen - unten einbinden garantiert keineswegs, dass die Sache auch tatsächlich später geladen wird.

Frameworks auf ein CDN auslagern und "oben" einbinden ist da wesentlich Zielführender.

• Use HTML semantically

"As an example, a navigation menu should always be an unordered list:"

Eigentlich sollte eine Navigation mit dem <menu />-Element ausgezeichnet werden, aber das wurde seltsamerweise als deprecated geflaggt nur um jetzt wieder ein nav-Element mit HTML5 einzuführen um dazu zusätzlich die List einzukasteln.

• Test WHILE you build to avoid cross-browser issues

Warum sollte das Testen wärend des Bauens Fehler vermeiden? Man erkennt Fehler Früher, vermeiden tut man sie dadurch noch lange nicht.

"If you test your documents on Firefox/IE/Chrome while your writing it, cross-browser rendering problems will be much easier to fix."

Ich würde vorschlagen, zum Testen immer einen möglichst Standardnahen Browser zu verwenden - das ist aktuell Opera - dicht gefolgt von Safari und Chrome. Gelegentlichens zwischendurch testen mit etwas einfacheren Browsern wie eben Firefox und antiken Browsern wie z.B. dem Internet Explorer können dann folgen.