- 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.