Über dieses Blog ..

.. schreibt man ja in der Regel was.

Mein Name ist Matthias und ich komme aus Karlsruhe. 1997 habe ich meine erste Website gebaut und seit 1999 arbeite ich als Frontend Entwickler und SEO.

In meiner Freizeit lässt mich dieses Thema auch nicht los und ich betreibe Just For Fun Wikis, Foren, Blogs über meine Hobbies und Interessen.

Nebenberuflich erstelle ich auch noch Webseiten für Firmen, Vereine und Privatpersonen.

Warum dieses Blog?

Das schöne an HTML ist das es jeder schnell erlernen kann und somit auch schnell seine eigene Website basteln kann.

Das doofe an HTML ist das man es “falsch” schreiben kann. Also das man viele Fehler im Quelltext machen kann, der Browser es aber meistens trotzdem zu ner funktionierenden Website zusammenbaut.

Wenn man jemanden nicht auf seine Fehler hinweist kann er sich nicht verbessern und es lernen richtig zu machen.

Und hier möchte ich ansetzen .. ich möchte jedem der mein Blog lesen will quasi helfen zukünftig bessern Quelltext zu schreiben und Fehler, die schon tausende von Webdesignern vor ihm gemacht haben, zu vermeiden.

jQuery – 2 – XML verarbeiten

In diesem Beispiel möchte ich zeigen wie man mit jQuery eine externe XML Datei verarbeiten kann.

Mein Beispiel soll eine kleine Bildergallerie zum Ergebnis haben. Alle Daten für die Bilder (Pfad und weitere Infos) werden in einem leicht zu bearbeitendem XML File gespeichert. Die Verarbeitung erfolgt mit jQuery und die Darstellung natürlich in HTML.

Hier mein Beispiel zum ausprobieren: XML Bildergallerie mit jQuery

Hier findet ihr die dazugehörige XML Datei.

Los gehts

$(document).ready(function(){
 $.get("jquery_xml.xml",{},function(xml){
  $('photo',xml).each(function(i) {

Die erste Zeile sollte nun klar sein. Mit $(document).ready(function() {}); wird sichergestellt daß das Dokument soweit geladen ist das es ohne Fehler manipuliert werden kann.

Dann holen wir uns das XML mit der Methode get. In der dritten Zeile bauen wir eine kleine Schleife mit each. Für jedes Element im XML File mit dem Namen photo soll eine Funktion i ausgeführt werden.

Die Funktion – XML auslesen

var imgPlace = $(this).find("place").text();
var imgTitle = $(this).find("desc").text();
var imgAddi = $(this).find("addi").text();

Hier schaut ihr euch am besten das zugehörige XML File an. Ich lege 3 neue Variablen an und weise diesen die Elemente place, desc und addi aus dem XML zu.

find sucht nach allen Elementen die in der Klammer folgen.
text legt fest das ich als Rückgabewert einen String haben möchte.

Die Funktion – HTML bauen

var output = '<div style="float:left; border:1px solid #c0c0c0; margin:10px;">';	
output += '<img class="loading" src="loading.gif" />';
output += '<img src="'+ imgPlace + '" /><br />';
output += '<b>'+ imgTitle +'</b><br />';
output += '<i>'+ imgAddi +'</i><br />';	
output += '<u>Bild: '+ ++i +'</u><br />';					
output += '</div>';

Wir beginnen einen DIV Tag .. faul wie ich bin hab ich die CSS Angaben einfach direkt reingeschrieben. Natürlich sollte man die CSS Angaben in ein externes Stylesheet auslagern.

img class=“loading” src=“loading.gif” zeigt die kleine Preloadgrafik an die nach kurzer Zeit ausgeblendet wird. In den folgenden Zeilen werden die vorher angelegten Variablen nun im HTML verarbeitet. Mit *Bild: ‘+ ++i +’ lege ich eine fortlaufende Bildnummer fest dich bei jedem Durchlauf um 1 erhöhe. Am Ende wird der DIV Tag wieder geschlossen.

In den Quelltext hängen

$("#inhalt").append(output);
$('.loading').fadeOut(1400);

In der ersten Zeile wird der Inhalt der Variablen output dem DIV Element inhalt im BODY Tag angehängt. Dies geschieht für jeden Durchlauf.

In der zweiten Zeile wir das Element mit der Klasse loading nach 1400 Millisekunden ausgeblendet. Somit verschwindet die Loading Grafik.

Hier nochmal die verwendeten Files:

Quelltext als HTML
Hier der Quelltext als TXT
Und das XML

jQuery – 1 – Einführung und Tooltip

jQuery ist eine freie, ziemlich umfangreiche JavaScript Bibliothek. jQuery bietet Funktionen zur DOM-Navigation und -Manipulation. Es unterstützt große Teile von XPath und CSS-Selektoren. Es bietet Programmierhilfen für Ajax wie Event-Handling und animierte Effekte.

jQuery wurde von John Resig entwickelt und im Januar 2006 auf dem BarCamp in New York veröffentlicht. Es lässt sich außerdem durch zahlreiche Plugins erweitern.

Hier findet ihr die jQuery Website

Ein Beispiel für jQuery Anwendungen sind z.B. Lightbox, Greybox, und Thickbox die ich schonmal angesprochen habe.

Warum jQuery?

Man kann das ganze doch auch in JavaScript direkt machen ..

  • jQuery trennt HTML und JS .. der Code bleibt “rein”
  • jQuery ist klein .. es hat nur 15 KB
  • Aufrufe und Logik sind simpler als in JS
  • In allen gängigen Browser (auch dem IE6) funktioniert jQuery
  • es spart einfach Zeit bei der Entwicklung

Bildervorschau mit jQuery – einfaches Beispiel

Hier mein Beispiel zum ausprobieren: Bildervorschau mit jQuery

Schaut euch den Quelltext an den ich nun etwas erleutere.

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
  $(document).ready(function() {
     // Dein Code 
   });
</script>

In der ersten Zeile wird das jQuery eingebunden. Am besten lädst du dir es von der jQuery Website herunter.
Mit $(document).ready(function() {}); wird sichergestellt daß das Dokument soweit geladen ist das es ohne Fehler manipuliert werden kann.

Da man nicht wissen kann wie schnell das Dokument beim User geladen wird ist dies eine der wichtigsten Funktionen in jQuery. Sie garantiert das die gewünschten Manipulationen erst dann durchgeführt werden können wenn der komplette Quelltext zur Verfügung steht.

Los gehts:

$("a.snapshot").append("<img src='exa.png' border='0' />");

Hier suchen wir nach allen A Tags mit der Klasse snapshot im Body bereich. Mit .append erweitern wir den A Tag um img src=‘exa.png’ border=‘0’ was dann nachher als kleines Icon (Lupe) hinter dem Text dargestellt wird.

Die Funktion – Auslesen:

$("a.snapshot").hover(function(pic) {
  trgt = $("a.snapshot");

Wenn nun die Maus über einen A Tag bewegt wird, der die Klasse snapshot hat, wird die Funktion (pic) aufgerufen. Der Variablen trgt wird der Inhalt des A Elements mit der Klasse Snapshot zugewiesen.

Die Funktion – Neues Element:

html = "<div id='viewpic' class='viewpic_style'><img src='" 
  + trgt.attr("href")
  + "' border='0' /><br /><b>"
  + trgt.attr("title")
  + "</b></div>";
   $(html).appendTo("body");

Der Variablen html wird nun ein neues DIV Element zugewiesen. Wir kleben hier quasi unser neues Element mit vorhandenen aus dem BODY Bereich ausgelesenen Inhalten zusammen. Mit trgt.attr(“href”) holen wir uns die URL des Bildes und mit trgt.attr(“title”) den Inhalt des TITLE Tags.

Mit * $(html).appendTo(“body”);* hängen wir den Inhalt der Variablen html in den BODY des Quelltextes.

Die Funktion – Mausoffset:

$('#viewpic').css ({
   left: (pic.pageX + 15) + 'px', 
   top: (pic.pageY + 18) + 'px'});

Damit das Bild beim Hover nicht am Mauszeiger klebt verrücken wir es um 15 Pixel nach rechts und um 18 Pixel nach unten.

Die Funktion – Anzeigen/Verbergen:

$('#viewpic').show();}
   ,function(pic) {$('#viewpic').remove();

Mit $(’#viewpic’).show();} wird das Bild angezeigt sobald es zum Mouseover kommt.
,function(pic) {$(’#viewpic’).remove(); ist die Angabe für den Mouseout. Fehlt diese würde das Bild nachdem man den Link mit dem Mauszeiger verlassen hat nicht ausgeblendet.

Hier nochmal das Beispiel: Tooltip mit jQuery
Hier der Quelltext im TXT Format

So das war mein erstes kleines HandsOn jQuery. Ich lerne auch gerade noch .. hoffe es folgen noch ein paar.

W3C valide Webseiten – 8 – Accessibility für Nutzer

Ein weites Feld .. erst mal ein Überblick. Es geht hier um beschreibungen für Bilder, relative Einheiten für die Schriftgröße, zugängliche Formulare und Tabellen, ausreichend Helligkeit/Kontrast bei den Farben, sind Linktexte beschreibend?

ALT-Attribut

In den ALT Bereich eines Bildes gehört ein kurzer beschreibender Text. Für längere Beschreibungen verwendet man den LONGDESC Tab. Mit diesem kann man dann auf weitere Informationen zu dem Bild verweisen.

Ein Bild mit korrektem ALT Tag:

<img src="sommerwiese.jpg" alt="Sommerwiese" longdesc="sommerwiese.htm">

Der ALT Tag kann auch für INPUT– und APPLET Elemente verwendet werden.

Relative und Absolute Schriftgröße

Die richtige Schriftgröße gibt es wohl nicht .. das liegt daran das es zig verschiedener Auflösungen und Monitorgrößen gibt. Es gibt mobile Endgeräte, Konsolen usw. die alle auf ein und die gleiche Website zugreifen und das selbe recht auf ne ordentliche Darstellung haben. Ein Smartphone kommt mit 400×280 Pixel Auflösung daher, ein Netbook mit 1024×600 Pixel, ein Office PC mit 1280×1024 und ein Rechner für Grafikdesign und Entwicklung mit 2560×1600 Pixel.

Doof nicht?

Daneben kann man Schriftgrößen ABSOLUT bzw. RELATIV angeben.

Absolut:

h2 {font-size:15pt; color:#ff0000;}

Relativ:

h2 {font-size:1.2em; color:#ff0000;}

*Eine gute Übersicht und Erklärung gibt es bei SelfHTML*

Man kann hier generell keine Empfehlung aussprechen welche Einheit die richtige ist. Einerseits kann man sagen ein Pixel ist IMMER ein Pixel. Allerdings haben unterschiedliche Monitore unterschiedliche Pixeldichten. Bei pixelbasierten Layouts mit fest definierten Breiten und Höhen (in Pixel) ist die Pixelangabe der Schriftgröße auf jeden Fall kein Fehler.

Generell empfiehlt es sich sowieso auf unterschiedlichen Betriebssystemen und Browsern seine neue Website zu testen. Unter Windows wird 96dpi (Dots per Inch) als Berechnungsgrundlage für die Darstellung von Schriftarten verwendet unter Linux und MacOS sind es 72dpi. Was unter Windows gut aussieht kann dann unter Ubuntu oder SUSE ziemlich klein aussehen.

Das W3C empfiehlt den Einsatz von relativen Schriftgrößen um eine größt mögliche Barrierefreiheit zu erreichen. Mit dem Einsatz von relativen Schriftgrößen lässt sich die Schriftgröße auf Wunsch vom User selbst vergrößern oder verkleinern.

Beschreibende Linktexte

Für weitere Informationen klicken Sie bitte hier

So ein Link ist gelinde gesagt “scheisse”. Klar .. der Benutzer der den Kontext des Links kennt kann damit vielleicht etwas Anfangen .. aber für z.b. blinde Benutzer oder Suchmaschinen ist das einfach Müll … da nicht aussagekräftig.

Ein Aussagekräftiger Link:

<a href="http://www.getmad.de/blog/" title="Blog von Matthias">Mein privates Blog</a>

Der Linktext selbst weißt mich darauf hin wo mich der Link hinführt .. und im TITLE Tag lassen sich noch weitere Informationen unterbringen.

Verwendete Farben

Eine Farbenblindheit bzw. Farbenfehlsichtigkeit liegt bei ca. 5% aller Menschen vor. Desshalb und auch um “normalsichtige” User nicht zu quälen sollte man kontrastreiche Farben einsetzen. Dunkelgrüne Schrift auf schwarzem Hintergrund ich einfach nicht (mehr) cool.

Wichtige Informationen sollte nicht nur mit Farben hervorgehoben werden. Menschen die an Grünbildheit leiden können rote von grünen Farben nicht unterscheiden und desshalb nicht erkennen.

Wie wird eure Website von Farbenblinden gesehen?

W3C valide Webseiten – 7 – Grad der Trennung von Inhalt und Layout

Vor CSS hat man sämtliche Layoutinformationen direkt in den Quelltext der HTML Datei geschrieben. Dies hatte zur Folge, daß Angaben über das Layout und der eigentliche Inhalt der Website im Quelltext vermischt wurden.

Für den menschlichen Besucher der Seite stellt dies natürlich kein Problem dar, da dieser sowieso nur die fertige Seite sieht. Für jeden BOT und jedes Program das auf die maschinenlesbarkeit einer Website angewießen war ist es allerdings eine unüberbrückbare Hürde.

Bevor CSS zum Einsatz kam wurde alles im HTML notiert:

HTML:

 <font color="#ff0000" face="ARIAL" size="7">CONTENT</font> 

Mit CSS und ausgelagerter CSS Datei:

CSS:

 font.xyz {color:#ff0000; face:ARIAL; size:20px;} 

HTML:

<font class="xyz">CONTENT</font>

Hier sieht man nun recht schnell wie man die Formatierung vom eigentlichen Inhalt trennen kann. Ein weiterer Vorteil ist das ich natürlich nur eine CSS Datei für jede beliebige Zahl von Webseiten brauche. Änderungen am Layout müssen so nur an einer Stelle gemacht werden und wirken sich auf das komplette Projekt aus.

Durch den Einsatz von CSS speckt man den HTML Quelltext ab.

Dadurch macht man es den Suchmaschinen natürlich einfacher und sie crawlen den Quelltext auch schneller, da die Dateigrößen natürlich ebenfalls geringer sind.

Sie müssen sich natürlich auch nicht durch Massen von unwichtigen Layoutinfos kämpfen.

Das ausgelagerte Stylesheet wird wie folgt im HEAD Bereich in den Quelltext eingebaut:

<link rel="stylesheet" type="text/css" href="/style/sheet.css" media="screen" /> 
<link rel="stylesheet" type="text/css" href="/style/print.css" media="print" />

In meinem Beispiel kann man nun noch einen weiteren Vorteil erkennen. Man kann unterschiedlichen Ausgabemedien unterschiedliche Stylesheets zuweisen. In diesem Falle einmal eins für den Monitor (media=“screen”) und eins für den Drucker (media=“print”).

Ebenso kann man natürlich unterschiedliche Styles für unterschiedliche Browser realisieren.

Konkret:

Man muss heute alle Informationen die nichts thematisch mit der Seite zu tun hat auslagern. Dazu gehören natürlich wie gerade erwähnt Layoutangaben, aber auch Grafiken die nur dem Layout dienen (Pfeile, Hintergünde, Buttons) müssen ins CSS ausgelagert werden.

Nur Bilder die unabdingbar für den Inhalt sind und konkret damit zu tun haben .. haben auch eine Verlinkung direkt im Quelltext verdient.

W3C valide Webseiten – 6 – Struktur/Deadlinks/Größe

Im Teil 6 will ich ein paar Details ansprechen die oft nicht soo wichtig erscheinen.

Struktur

Hier geht es primär um sematisch korrektes Markup. Dabei sollte man sich die Frage stellen ob die gegebenen HTML Elemente auch nach ihrer Bestimmung verwendet werden. Beispiele sind hier die H Tags die man für Überschriften verwenden sollte, P Tags für Text oder die UL und LI Tags um Auflistungen auszuzeichnen.

Warum macht das Sinn? Suchmaschinen oder abgespeckte Browser die kein CSS darstellen können sind damit in der Lage alle Elemente der Seite entsprechend ihrer Logik darzustellen. Konkret bedeutet das Suchmaschine un Browser wissen, wenn ihr die Tags korrekt benutzt was in welcher Gewichtung und zu welchem Zweck dargestellt wird. Die kann natürlich nicht passieren wenn ihr alles DIV durchformatiert und die Layoutangaben im CSS macht.

Ihr macht es hiermit allen einfacher die Textbrowser, mobile Browser oder Browser ohne CSS verwenden.

Deadlinks

Klar .. Deadlinks nerven. Aber wenn ihr eure Website nicht auf Deadlinks checkt macht ihr es Suchmaschinen unötig schwer euren Inhalt zu indizieren. Suchmaschinen folgen in der Regel jedem Link den sie finden und können alle Inhalte eurer Seite dann im Kontext indizieren .. allerdings eben nur wenn ihr keine Deadlinks habt.

Das W3C stellt euch sogar einen Deadlinkchecker zur Verfügung: http://validator.w3.org/checklink

Größe der Website / Geschwindigkeit

Wirklich jeden nerven langsame Webseiten bzw. irgendwelche Flash Animationen die erst mal 2 Minuten laden müssen bevor etwas passiert. Die meisten User sind nicht bereit ihre Zeit mit so etwas zu verschwenden. In Zeiten von Breitbandverbindungen etc. ist das zwar nicht mehr so problematisch wie noch zu ISDN Zeiten aber trotzdem ein Faktor. Seit also sparsam mit Bildern bzw. macht euch die Mühe und baut Thumbnails die man groß klicken kann.

Sucht euch Hoster die über schnelle Internetverbindungen verfügen und wenn ihr speziell ein Angebot für mobile Endgeräte baut dann achtet darauf das hier noch viele mit GPRS surfen und selbst UMTS nicht immer Highspeed liefert.

Gängelt eure Besucher nicht mit unötigen Wartezeiten.

W3C valide Webseiten – 5 – Unnötige Klassen

Viele Anfänger begehen den Fehler wahre DIV Gemetzel im HTML Quelltext anzurichten. Da wird dann alles und jedes irgendwelchen Pseudoklassen zugewiesen ohne ein bischen nachzudenken. Das mag zwar im Validator korrekt sein aber es ist nicht schön und auch nicht optimal für Suchmaschinen.

Hier das SCHLECHTE Beispiel:

HTML

<div id="headline">Überschrift</div>
<p class="subheadline">Unterüberschrift</p>

CSS

#headline {color:#000}
P.subheadline {font-style:italic}

Was passiert hier?
Die erste Zeile enthält die Hauptüberschift in dem Dokument. Die zweite Zeile eine Bereichs oder Unterüberschrift. Valide ist das auf jeden Fall .. aber nicht schön. In HTML gibt es für solche Fälle extra Tags (hier bietet sich der H Tag an)

Hier das GUTE Beispiel:

HTML

<h1>Überschrift</h1>
<h2>Unterüberschrift</h2>

CSS

H1 {color:#000}
H2 {font-style:italic}

Ich denke das leuchtet ein. Und um jetzt auch noch einen gewichtigen Grund zu nenen warum man da so machen sollte: Suchmaschinen achten auf HTML Tags … Text der in H Tags verpackt wird ist tendenziell wichtiger für die Suchmaschine als Text der z.b. in eine P Tag gepackt wird. Das wird mittlerweile von den meisten Suchmaschinen exakt so umgesetzt. Eure Keywords werden es euch also danken wenn ihr aussagekräftige Überschriften in H Tags einfügt.

W3C valide Webseiten – 4 – Valides CSS

Neben einem validen HTML Quelltext spielt es natürlich ebenso eine Rolle ob das CSS valide ist. Es gibt vom W3C ebenfalls einen CSS Validator in dem man seine CSS Files auf Konformität prüfen kann.

Jigsaw CSS Validator

Viele Fehler die im HTML Dokument bei der Vorschau im Browser auftauchen rühren meist von fehlerhaften CSS Dateien. Da hat man mal ein Strichpunkt oder eine Klammer vergessen und schon kackt das ganze Layout ab.

Ein häufiger Fehler ist auch folgender:

h1 {margin-left: 5 px;}

Es ist grundsätzlich falsch ein Leerzeichen zwischen Wert und ein Einheit einzufügen.

Korrekt ist also:

h1 {margin-left: 5px;}

Und was ist mit Browser Hacks?

Die meisten populären Browserhacks für alte Browser haben sich (zum Glück) nicht auf neue Browserversionen ausgewirkt. Aber grundsätzlich sollte man soweit es geht auf Browserhacks verzichten und komplett validen Code schreiben. Es ist einfach nicht auszuschließen das in einem zukünftigen Browser der Hack falsch interpretiert wird .. dann steht man doof da und muss wieder an den Quelltext und das CSS ran und fixen.

W3C valide Webseiten – 2 – Zeichensatz / 3 – Valider Code

Der zweite Teil .. heute geht es um den Zeichensatz und um W3C validen Code.

2 – Zeichensatzcodierung

Wenn ein Browser keine Zeichensatzcodierung findet kann dem Benutzer unter Umständen ein unlesbarer Text präsentiert werden. Mit der Zeichensatzcodierung teile ich also den Browser mit welche Zeichen (Schrift, Sonderzeichen usw.) ich in meinem Dokument verwende.

Es gibt derzeit 15 Zeichensätze unter der Norm ISO 8859 (beispielsweise ISO-8859-1 = Latin-1, Westeuropäisch / ISO-8859-5 = kyrillisch). In ISO-8859-1 sind natürlich keine kyrillischen Zeichen vorhanden.

Daneben gibt es noch UTF-8. UTF-8 basiert auf Unicode. Unicode ist eine Zeichentabelle in der alle Zeichen oder Textelemente die es auf der Welt gibt vorhanden sind.

Korrekte Auszeichnung für XML:

<?xml version="1.0" encoding="utf-8" ?>

Korrekte Auszeichnung für HTML:

<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1" >

Korrekte Auszeichnung für XHTML:

<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-5" />

Welchen Zeichensatz benutzen?

Am sichersten ist man IMMER mit UTF-8 allerdings muss man hier die Sonderzeichen immer codieren. Wenn man von vorneherein weiß das man seine Website nur auf Deutsch betreibt und auch nur deutsche User anspricht .. spricht meiner Meinung aber auch nichts dagegn ISO-8859-1 zu verwenden.

3 – Valider Code

Wieso sollte man validen Code schreiben:

  • valider Code rendert schneller
  • valider Code rendert besser
  • Suchmaschinen crawlen besser durch validen Code
  • Browser werden immer standardkonformer und man spart sich “Browseroptimierungen”

Mehr will ich dazu nicht sagen .. ich denke jedem guten Webdesigner sollte die notwendigkeit von validen Webseiten klar sein.

W3C Validator – Hier könnt ihr euren Code checken lassen

W3C valide Webseiten – 1 – Document Type Definition

Ich möchte eine kleine Serie starten über W3C valide Webseiten. Das W3C (World Wide Web Consortium) ist ein Gremium zur Standardisierung der das WWW betreffenden Techniken.

Warum ist es so wichtig sich an Webstandards zu halten?

  • damit Webseiten in ALLEN Browsern funktionieren .. schreibt man nur für den IE 6 kann man fast davon ausgehen das die Website nicht korrekt in anderen Browsern dargestellt wird.
  • damit die Maschinenlesbarkeit erhalten bleibt. Suchmaschinen präferieren Webseiten die über validen Quelltext verfügen .. z.B. Flash kann von derzeit keiner Suchmaschine durchsucht werden.
  • um seine Website Menschen mit Behinderungern zugänglich zu machen
  • um zukunftskompatibel zu bleiben .. wenn ein Quelltext aus nicht konformen Bestandteilen besteht können ihn neue Browser oder Browser anderer Hersteller nicht mehr korrekt ausgeben
  • um sich Workarounds zu sparen und damit vor allem Geld und Zeit

1 – DTD (Document Type Definition)

Der Doctype steht am Anfang des Dokuments und informiert den Validator darüber, welche (X)HTML-Version verwendet wird.

Steht keine DTD am Anfang eines Dokuments schalten viele Browser in den sog. Quirks Mode. Der Quirks Mode wurde eingeführt um Abwärtskompatibilität zu Websites sicherstellen, die veralteten oder ungültigen HTML– oder CSS-Code verwenden. Dabei werden auch Darstellungsfehler simuliert, damit das Layout dieser Webseiten nicht zerstört wird.

Wenn eine DTD am Anfang des Dokuments steht geht der Browser in den Standard Mode und stellt die Website W3C konform da.

Doctypes sind also Schlüsselkomponenten von W3C konformen Webseiten, ohne die Markup und CSS nicht (korrekt) validiert werden können.

So sieht eine korrekte DTD eines xHTML Dokuments aus die nach xHTML 1 Strict validiert werden soll:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Eine komplette Übersicht aller Typen findet sich beim W3C

Egal für welche DTD ihr euch entscheidet .. ich empfehle XHTML (Strict oder Transitional) .. sie muss in jedem eurer HTML Dokumente an erster Stelle drinstehen.