Googles Coding-Guidlines für HTML & CSS

Google hat vor kurzen eigene Guidlines für HTML & CSS vorgestellt. Solche Coding-Guidlines sind gut, damit der Quellcode z.B. in einem Projekt immer gleich aussieht. So ist der Code geordneter und man weiß bei einigen Sachen so ungefähr wo man suchen kann. Coding-Guidlines können auch dafür sorgen, dass performant programmiert wird. So können strukturbasierende Performanceengpässe vermieden werden.

Coding-Guidlines für HTML & CSS habe ich bisher nur im kleinen Umfang gesehen. Google hat da schon einiges aufgestellt. Eine Einhaltung der Guidlines wird die Crawlbarkeit erleichtern, die Performance steigern, sowie auch die Vermeidung von browserspezifischen Fehlern.

Im Endeffekt habe ich dort viele Sachen gefunden, die ein guter Entwickler eigentlich schon kennen sollte. Aber neben den „normalen“ Sachen habe ich auch ein paar Regeln gefunden, die ich bisher so nicht angewendet habe, die aber trotzdem Sinn ergeben.

Protokoll

Google schlägt vor das http: und https: bei Scripten, Stylsheets wegzulassen, damit die Seite ohne Probleme mit und ohne https läuft.
Beispiel: //blog.stevieswebsite.de statt http://blog.stevieswebsite.de.

Todo

Aufgaben sollen als Kommentar mit  gekennzeichnet werden. Hier ist es aber von Vorteil, wenn man PHP-Kommentare oder Ähnliches benutzt, damit diese nicht an den Browser übergeben werden.

Umlaute sollen Umlaute bleiben

Google lehnt das Kennzeichnen von Umlauten, wie zum Beispiel dem ü mit ü ab. Dies sollte stattdessen durch die UTF8-Kodierung geschehen.

Kein `<head>` kein `<body>`

Seit HTML5 ist es möglich, den Head- bzw. den Body-Tag auszulassen. Und dies möchte Google auch, um den HTML-Quelltext schmaler zu machen.

type Attribute auslassen

Beim Script- oder Style-Tag, gibt man ja häufiger mal den type (z.B. mit text/css) an. Seit HTML5 ist auch dies nicht mehr erforderlich und sollte auch nicht mehr gemacht werden.

CSS IDs und Klassen so kurz wie möglich

IDs und Klassen sollten so kurz wie möglich aber so lang wie nötig sein. Als Beispiel wird aus navigation nav gemacht, aus atr aber author.

Keine CSS-Selection aus Kombination mit id/classe und typ

Statt input.color sollte man dann nur noch .color benutzten. Für verschiedene Typen kann man sich dann mit neuen Klassen aushelfen. Dies soll sich positiv auf die Performance auswirken.

Namen, ids und Klassen durch Bindestrich trennen

Ich persönlich nutze entweder CamelCasing, oder Unterstriche um Wörter in Namen usw. zu trennen. Besser wäre laut Google aber Bindestriche zu nutzen.

Mehr Regeln

Das waren nur die Regeln, die ich bisher noch so gar nicht angewand habe. Ein Blick in die Guidlines lohnt sich auf jeden Fall! Wenn ihr noch eine Regel findet, die dort noch nicht ist, bzw. eine, der ihr so gar nicht zustimmen könnte, könnt ihr euch gerne in den Kommentaren auslassen 😉

Du arbeitest in einer Agentur oder als Freelancer?
Dann wirf doch mal einen Blick auf unsere Software FeatValue.

Kommentare

Danny schrieb am 05.05.2012:

Um den head wegzulassen bin ich einfach zu konserativ :)

Stefan Wienströer schrieb am 05.05.2012:

Das kostet schon überwindung. Selbst die Goolge Startseite setzt "noch" auf den Head ;-)

Abro, Lucido Media schrieb am 06.05.2012:

Ok, ich verstehe dass Big Mama G. genau solche Guidelines herausgibt - überhaupt Richtlinien zu haben, an die sich ein Team hält, ist toll und Ladezeit ist Geld. Viele der dort gelistete Regeln benutzen sicher eh schon die meisten von uns; weil's flauschig ist und einfach Sinn macht. Mitten in diesem wunderhübschen Ideen-Pool gibt es aber auch 2, 3 Empfehlungen bei denen mir der Gedanke kommt ob ich mir nicht lieber die Hände abhacken möchte, als so etwas wirklich umzusetzen. Es ist sicher gerechtfertigt dass einem stellenweise die Augen bluten, wenn man Jahre lang diverse Leute mit seinem Webstandards-Fanatismus genervt hat und v.A. wenn man ästhetischen, lesbaren & wartbaren Code liebt. Die ganzen tollen Optimierungen kann man im Zweifel vor der Ausgabe durch 'nen Preprozessor vornehmen lassen. Wenn ich erwarte dass es mehr als nur ein paar Zeilen Code werden und ich sie später nochmal anfassen muss, dann bringt mir die vorgeschlagene Syntax IMHO mehr Nach- als Vorteile. HTML5 nach XHTML-Regeln ist für mich sicher noch eine ganze Weile die Best Practice. Auf der anderen Seite ist's zugegebener Maßen trotzdem ein netter Denkanstoß und auch mal toll zu sehen dass man die eigenen Crawler überarbeiten muss ;o)

Über uns

Wir entwickeln Webanwendungen mit viel Leidenschaft. Unser Wissen geben wir dabei gerne weiter. Mehr über a coding project