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.

Browsermarktanteile 2008

Eigentlich spielt es keine Rolle welchen Marktanteil welcher Browser hat. Eine gut geschriebene Website wird in allen gängigen Browser gleich aussehen. Die Frage die sich also stellt gegen welche Browser muss man seine Website testen?

Marktanteile auf einer deutschen B2B Website:

  • Internet Explorer: 67.20%

    Verteilt sich wie folgt :

    6.0: 53.96%
    7.0: 45.56%
    5.5: 0.22%
    5.01: 0.13%
    8.0: 0.10%

  • Firefox: 28.48%

    Verteilt sich wie folgt:

    1.x: 1%
    2.x: 15%
    3.x: 74%

  • Opera: 2.42%

    Verteilt sich wie folgt:

    9.x: 97%
    8.x: 2%

  • Safari: 0.73%
  • Mozilla: 0.72%
  • Konqueror: 0.13%
  • Netscape: 0.11%
  • Chrome: 0.09%
  • SeaMonkey: 0.06%

Marktanteile auf nem privaten Webblog zum Thema Automobile:

  • Internet Explorer: 48.62%

    Verteilt sich wie folgt :

    7.0: 67.12%
    6.0: 31.42%
    8.0: 1.19%
    5.5: 0.16%

  • Firefox: 40.01%

    Verteilt sich wie folgt:

    2.x: 15%
    3.x: 74%

  • Safari: 7.69%
  • Opera: 2.31%
  • Chrome: 0.71%
  • SeaMonkey: 0.24%
  • Camino: 0.12%
  • Mozilla: 0.09%

Interpretieren soll hier nun jeder selbst .. die herangezogenen Seiten sind representativ und haben mehrere 1000 Besucher jeden Tag.

Fakt ist allerdings:

Man muss neue Webseiten auf jeden Fall in IE 6, IE 7 und IE 8 checken. Jeder dieser Browser rendert unterschiedlich .. das ist also zwingend.

Ebenso muss man mit der neusten Version von Firefox arbeiten.

Opera sehen ich ebenso als Pflicht an obwohl sich hier am Marktanteil in den letzten Jahren wenig getan hat. Allerdings wird dieser auf vielen mobilen Endgeräten eingesetzt.

Safari und Chrome sind definitiv die Newcomer .. die HTML Rendering Engine ist hier allerdings identisch. Beide Browser nutzen WEBKIT zum rendern von CSS und HTML Files. Nur bei Javascript werden unterschiedliche Engines eingesetzt.

Heisst aber: An Chrome und Safari komme ich ebenso wenig vorbei und deren Marktanteile werden dank der wachsenden Marktmacht von Apple und Google in den nächsten Jahren definitiv zulegen.

Während man es früher als noch recht einfach hatte und gegen den IE 5/6 und den Netscape Navigator gecodet hat .. wird es zunehmend zeitaufweniger vor allem wenn man seine Webseite in allen Browservarianten testen möchte. Als Windows User hat man es hier sicher am einfachsten .. das es nun auch den Safari für Windows gibt. Bei Mac und Linux hilft wahrscheinlich nur Virtualisierung eines XP Systems .. oder wie bei so vielen ein alter XP Laptop zum checken.

Multiple IEs auf einem System

Der Internet Explorer löscht bei einem Update die alte Version. Theoretisch ist es nicht möglich verschiedene IE Versionen auf einem System zu betreiben. Hier hilft euch ein nettes kleines Prog: Multiple IEs
Damit könnt ihr IE 3 – 6 parallel zum IE 7 auf einem XP System installieren.

Und der ganze Rest?

Nicht jeder hat die Möglichkeit seine Webseiten auf allen Browsern zu checken. Ob zumindest optisch alles passt lässt sich auf Browsershots herausfinden. Hier kann man seine Website auch auf sehr exotischen Browsern/Betriebssystemen überprüfen lassen.

Browser- / CSS Hacks – Internet Explorer

Browser oder CSS Hacks sind Anweisungen die im CSS geschrieben werden.
Das Problem ist, daß unterschiedliche Browser ein und denselben Befehl unterschiedlich darstellen. Besonders erwähnt sei hier der Internet Explorer 5 bzw. 6 deren CSS 2 Unterstützung gelinde gesagt mangelhaft ist. Desshalb gehen folgende Hacks besonders drauf ein spezielle Anweisungen für die Microsoftbrowser zu schreiben ohne andere Browser zu beeinflussen.

Kind-Selektor oder Child Selector

Der Kind Selektor wird von keiner Version des Internet Explorer ausgelesen (bis einschließlich Version 7). Er eignet sich also um Formatierungen vor dem IE zu verstecken.

html>body b {color: red;}

Konkret:
Alles was unterhalb des body Elements fett (b) geschrieben ist hat eine rote Schriftfarbe. Im IE wird das nicht erkannt und das Element wird nur fett und nicht fett und rot dargestellt.

Star Hack

Der Star Hack wird von allen Internet Explorern bis einschließlich Version 6 ausgelesen. Andere Browser ignorieren ihn.

div.content {width:600px;}
* html div.content {width:650px;}

Konkret:
In allen Browsern wird das div.content in 600 Pixel Breite dargestellt. Der IE zeigt es jedoch in 650 Pixel Breite an.

Star Plus Hack

Der Star Plus Hack wird nur vom Internet Explorer 7 interpretiert. Andere Browser ignorieren ihn.

div.content {width:600px;}
*:first-child+html div.content {width:650px;}

Konkret:
In allen Browsern wird das div.content in 600 Pixel Breite dargestellt. Der IE 7 zeigt es jedoch in 650 Pixel Breite an. Lässt man den Bereich first-child weg wird er ebenso von Opera interpretiert.

Lightbox, Greybox, Thickbox usw. – Bilderanzeige auf der Website

Um Bilder und vor allem eine Bildergallerien optisch ansprechend im Web zu präsentieren verwendet man mittlerweile einige pfiffiges Javascripts. Die Teile nennen sich Thickbox, ThickerBox, GreyBox, GreyBox Redux, Leightbox, Lytebox usw.

Die Dinger machen irgendwie alle das gleiche .. wer jetzt keine Ahnung hat wovon ich rede kann sich hier mal ein Beispiel ansehen. Man kann also coole Bildergalerien auf seiner Website einbinden. Alles was es dazu braucht sind ein paar Javascripts und ein CSS File

Das ursprüngliche Script heisst Lightbox und wurde von Lokesh Dhakar geschrieben. Mittlerweile gibt es jede Menge weiterer Scripte die ganz unterschiedliche Dinge leisten.

Hier nun ein Überblick:

  • Thickbox
    jQuery, AJAX, erlaubt Bilder oder HTML
  • Slightly ThickerBox
    quasi ein Klon der Thickbox, integriert “Vor” und “Zurück” also perfekt für ganze Gallerien
  • GreyBox
    ein etwas anderer Ansatz in der optischen Präsentation
  • GreyBox Redux
    die Greybox etwas abgespeckt, auch für HTML Darstellung
  • Multifaceted Lightbox
    4 verschiedene Datentypen die in die Box geladen werden können: Strings, Bilder, Elemente und AJAX
  • Leightbox
    Der Inhalt der Box steht im HTML also auch für Suchmaschinen geeignet
  • xilinus
    sehr ausführliches und umfanreiches Script das nahezu keine Wünsche offen lässt
  • Lightbox Plus
    Lightbox plus mehr Features z.b. automatisches Resizing
  • Litebox
    schlanke und abgespeckte Version der Lightbox
  • iBox
    für Bilder, HTML, AJAX, Login Boxen usw.
  • Slimbox
    superschlanker Lightbox Klon (16KB) 100% kompatibel mit der ursprünglichen Lightbox
  • Lytebox
    gefällt mir persönlich fast am besten

Es gibt noch einige mehr .. aber mit dieser Liste müsste man alle gängigen Einsatzgebiete erschlagen. Die Lightbox gibt es z.b. auch als Plugin für WordPress oder Serendipity.

Webstandards

Das 42blue Blog über Webstandards, (x)HTML, CSS, Grafikbearbeitung, XML, Java Script, Browser und alles was in entferntester Weise mit dem Web und den Technologien dahinter zu tun hat. Ich arbeite Hauptberuflich als Webdesigner und stolpere täglich über soviele Dinge die mir nützlich und lästig sind das sie das Blog hier innerhalb von kürzester Zeit wie fast von alleine füllen sollte.

Ich erhebe mit diesem Blog keinen Anspruch auf Vollständigkeit, Richtigkeit oder sonst irgendwas. Es soll einfach für mich und alle anderen die es brauchen ein Nachschlagewerk werden in dem ich alles was mit Webtechnologien und Webstandards zu tun hat sammle.

Heute ist der 28 November 2008 und das ganze war eine spontane Idee.