Webmaster-Zentrale » HTML + CSS

Der Umstieg auf HTML5

Webmaster — Sat, 06 Aug 2011 21:37:15 +0000

Gestern habe ich im Artikel Das HTML5-Handbuch ein Buch zum Thema HTML5 vorgestellt. In diesem Beitrag findet ihr jetzt noch weitere Informationen darüber, wie der Umstieg auf HTML5 funktioniert, von welchen Browsern der neue Standard unterstützt wird und welche Auswirkungen er auf die Suchmaschinenoptimierung einer Webseite haben kann. Abschließend gibt es auch noch ein HTML5-Gewinnspiel.

Browser-Unterstützung von HTML5

Das offizielle HTML5-Logo

HTML5 ist zurzeit noch ein Arbeitsentwurf und wird voraussichtlich erst ab 2014 endgültig verabschiedet. Trotzdem wird es von allen aktuellen Browsern unterstützt, allerdings je nach Modell in unterschiedlichem Ausmaß. Laut html5test.com kann Chrome12 im Vergleichstest die meisten Punkte ergattern. Schlusslicht ist weit abgeschlagen der Internet Explorer 9.

Aber auch ältere Browser, die den neuen Standard offiziell nicht unterstützen, zeigen HTML5-Seiten einwandfrei an, solange keine neuen Funktionen verwendet werden. Denn HTML5 ist sowohl zu HTML 4.01 als auch zu XHTML voll abwärtskompatibel.

Umstieg auf HTML5 per Doctype

Zur Umstellung auf HTML5 reicht es aus, einfach nur den Doctype einer Webseite zu ändern. Während es bisher für HTML 4.01

und XHTML

2 verschiedene, recht komplizierte, Doctypes gab, wurde dieser für HTML5 und folgende Versionen stark vereinfacht:

Wer auf HTML5 umstellen möchte, braucht also nur einen der bestehenden Doctypes durch den neuen zu ersetzen.

Screenshots mit Browsershots.org

Wer auf Nummer sicher gehen und wissen möchte, ob sich die Darstellung durch die Änderung des Doctypes unter HTML5 verändert hat, kann sich auf Browsershots.org Screenshots unter verschiedenen Browserversionen anzeigen lassen und so überprüfen, ob wirklich alles geklappt hat.

Vorteile der neuen HTML5-Elemente

HTML5 bietet einige neue Tags, die die Semantik, also die Verständlichkeit des Codes, verbessern. Für die meisten Endanwender ist es sicherlich nicht so wichtig, ob eine Navigation wie bisher als

oder wie unter HTML5 als

ausgezeichnet wird. Der zweite Code dürfte aber den Suchmaschinen ihre Arbeit wesentlich erleichtern und damit zumindest in der Zukunft zu einer besseren Suchmaschinenoptimierung führen, wie Torben Leuschner in seinem Artikel Vorteile von HTML5 aus SEO-Sicht schreibt.

WordPress auf HTML5 umstellen

Wer seinen Blog umstellen möchte, hat es besonders einfach, denn ab Version 3.2 hat auch WordPress den Umstieg auf HTML5 vollzogen. Voraussetzung dafür ist allerdings, dass man das neue Standardtheme Twenty Eleven oder ein anderes speziell für HTML5 angepasstes Theme verwendet.

HTML5-Gewinnspiel

Verwendet ihr auf euren Webseiten bereits HTML5 oder wollt ihr noch etwas warten? Was spricht aus eurer Sicht für bzw. gegen den Umstieg auf HTML5? Unter allen, die per Kommentar ihre Meinung dazu hinterlassen, verlose ich:

1 t3n-Jahresabo im Wert von 35 Euro
3x die Ausgabe Nr. 24 der t3n

Teilnahmeschluss für das Gewinnspiel ist Sonntag, der 14. August 2011.

Jetzt lerne ich HTML5: Start ohne Vorwissen

Das HTML5-Handbuch

Webmaster — Fri, 05 Aug 2011 06:03:03 +0000

Stefan Münz dürfte den meisten bekannt sein als Gründer von SELFHTML, der Website, die lange Zeit DIE HTML-Referenz war. Nachdem die Seite aber schon seit über 4 Jahren nicht mehr aktualisiert wurde, ist sie inzwischen überholt und veraltet. Infos über aktuelle Techniken wie HTML5 und CSS3 sind dort nicht zu finden. Stattdessen hat sich Stefan Münz zusammen mit seinem Co-Autor Clemens Gull entschlossen, ein Buch über die modernen Webstandards zu veröffentlichen. Das HTML5-Handbuch beinhaltet über 700 Seiten. Ob sich der Kauf dieses stattlichen Werkes lohnt, erfahrt ihr in diesem Artikel.

HTML5 für Umsteiger

Um es gleich vorneweg zu sagen: Das HTML5-Handbuch ist kein Einsteiger-Buch. Wer sich also bisher nicht mit HTML beschäftigt hat, sollte lieber auf ein anderes Buch zurückgreifen. Zwar werden in den ersten Kapiteln alle HTML5-Elemente ausführlich dokumentiert, dies findet aber nicht im Rahmen eines Workshops statt.

Zielgruppe des HTML5-Handbuchs sind eindeutig Umsteiger, die ihre Webseiten bisher mit HTML 4.01 oder XHTML ausgezeichnet haben. Diese finden neben den neuen HTML5-Elementen auch eine umfangreiche Erklärung der bereits bekannten Auszeichnungen. Dies gilt übrigens nicht nur für die üblicherweise verwendeten Elemente wie Links, Tabellen oder Formulare, sondern auch für eher unbekannte wie z. B. (Wer weiß, wofür man das verwendet?).

Mikrodaten, Scripting und CSS

Neben den reinen HTML5-Bestandteilen geht das HTML5-Handbuch auch ausführlich auf benachbarte Gebiete ein. So gibt es z. B. ein extra Kapitel nur für Mikrodaten (die man z. B. für elektronische Visitenkarten und zur Kalenderverwaltung verwenden kann). Javascript-Freunde werden außerdem mit 40 Seiten zu ihrem Thema bedient. Noch ausführlicher gehen die Autoren auf das Thema CSS ein. In 2 Kapiteln mit über 140 Seiten werden ähnlich wie im HTML5-Teil die einzelnen CSS-Definitionen erklärt. Dabei werden natürlich auch die Neuheiten von CSS3 vorgestellt und z. B. detailliert erklärt, wie man damit abgerundete Ecken erstellen kann.

XHTML und Anhang

2 weitere Kapitel beschäftigen sich mit den Unterschieden von HTML und XHTML bzw. den obsoleten (veralteten) HTML-Elementen. Mit knapp 200 Seiten bietet das HTML5-Handbuch auch einen sehr umfangreichen Anhang, der eine komplette Referenz aller HTML5- und CSS2-Elemente umfasst (CSS3 nur auszugsweise).

Fazit: Ich kann das HTML5-Handbuch allen empfehlen, die sich bisher schon mit HTML4 oder XHTML beschäftigt haben und jetzt auf HTML5 umsteigen wollen. Besonders gut hat mir an diesem Buch gefallen, dass auch auf benachbarte Gebiete eingegangen wird, die nicht direkt etwas mit HTML5 zu tun haben, aber doch irgendwie dazu gehören.

Das einzige, was ich ein wenig vermisst habe, war ein extra Kapitel, das sich ausschließlich dem Umstieg auf HTML5 widmet. Dieser ist zwar nicht so schwierig und die Informationen dazu sind natürlich auch alle im Buch enthalten. Trotzdem wäre es schön gewesen, wenn diese Infos in einem extra Kapitel gebündelt worden wären.

Umstieg auf HTML5 (mit Gewinnspiel)

Um die angesprochene Lücke zu schließen, gibt es morgen hier noch einen weiteren Artikel zum Thema HTML5, in dem ich beschreibe, was beim Umstieg zu beachten ist. Das Reinschauen lohnt sich übrigens doppelt, denn der Beitrag wird noch durch ein attraktives Gewinnspiel ergänzt

Der Umstieg auf HTML5

HTML5 Handbuch – Die neuen Features von HTML5

Adventskalender erstellen – Teil 1: Die Imagemap

Webmaster — Fri, 03 Dec 2010 21:37:45 +0000

Auf meiner Rätselseite gibt es ja seit vorgestern einen Adventskalender mit Preisen im Wert von mehr als 1.500 Euro. Die 24 Rätsel dafür wurden von 10 Usern des Rätselforums erstellt und auch die Kalendergrafik stammt von einem Rätselforum-User. Meine Aufgabe war es, den Adventskalender zu programmieren. Wie ich dabei vorgegangen bin, beschreibe ich in diesem Artikel.

Bei der Programmierung eines Adventskalenders gibt es 2 besondere Anforderungen, die bewältigt werden müssen. Zum einen müssen die jeweiligen Tage verlinkt werden. Am einfachsten wäre es logischerweise gewesen, wenn ich dafür 24 Textlinks verwendet hätte. Aber schöner sieht es natürlich aus, wenn die Tage auf der Adventskalendergrafik angeklickt werden können. Diese Funktion habe ich mittels einer sogenannten Imagemap in HTML umgesetzt.

Die zweite Schwierigkeit ist die, dass die Türchen natürlich nur an dem dafür vorbestimmten Tag geöffnet werden dürfen. Mit HTML lässt sich da nichts mehr machen, deshalb habe ich dafür PHP verwendet.

Vorbereitung des Adventskalenders

Der Rätsel-Adventskalender mit Raster

Bevor ich mit der Programmierung starten konnte, musste ich erst mal die Zahlen auf die vorhandene Kalendergrafik setzen. Ich habe mir dafür in paint.net eine zweite Ebene erstellt und dort ein Raster konstruiert. Mit Hilfe dieses Rasters und einer dritten Ebene war es dann nicht mehr so schwierig, die 24 Zahlen so zu positionieren, dass sie gleichmäßig auf der Grafik verteilt waren. Nachdem das erledigt war, habe ich das Raster wieder entfernt, so dass die Striche auf der endgültigen Kalendergrafik nicht mehr zu sehen sind.

Die Imagemap

Bei einer Imagemap handelt es sich um eine verweis-sensitive Grafik, d. h. es lassen sich beliebige Teile einer Grafik verlinken. Diese Technik wird sehr oft für Landkarten eingesetzt, auf der man durch einen Klick auf einen Ort Informationen darüber abrufen kann. Aber auch für die Programmierung eines Adventskalenders ist eine Imagemap sehr gut geeignet.

Damit der Browser weiß, dass eine Grafik verweis-sensitiv sein soll, muss diese mit dem Attribut “usemap” gekennzeichnet werden:

Bei dem Wert #Kalender handelt es sich einfach um einen Anker, der eine Verknüpfung mit dem map-Tag bildet.

Der HTML-Tag “map” leitet die Definition einer Imagemap ein und schließt die einzelnen Verweise ein. Der Wert “name” muss dabei natürlich der gleiche sein wie der Ankername des img-Tags.

Für eine Imagemap gibt es den area-Tag, der 3 Verweisarten ermöglicht: Vierecke, Kreise und Polygone. Für meinen Adventskalender habe ich die Vierecke verwendet, weshalb ich die beiden anderen Arten hier nicht näher beschreibe.

Das Attribut “shape” legt die Verweisart fest, in diesem Fall ist es “rect” für einen viereckigen Verweis. Die 4 Werte des Attributs “coords” haben folgende Bedeutung:

1. Wert: Der Pixel-Wert von links für die linke obere Ecke des Vierecks
2. Wert: Der Pixel-Wert von oben für die linke obere Ecke des Vierecks
3. Wert: Der Pixel-Wert von links für die rechte untere Ecke des Vierecks
4. Wert: Der Pixel-Wert von oben für die rechte untere Ecke des Vierecks

Das hört sich im ersten Moment vielleicht kompliziert an, ist aber im Grunde ganz einfach. Die beiden ersten Werte bestimmen die linke obere Ecke des Vierecks. Die im Beispiel angegebenen Werte “10,30″ besagen also, dass die linke obere Ecke 10 Pixel vom linken Rand und 30 Pixel vom oberen Rand entfernt sind. Die beiden anderen Werte bezeichnen die rechte untere Ecke. Die beiden Werte “125,100″ geben an, dass die rechte untere Ecke 125 Pixel vom linken Rand und 30 Pixel vom oberen Rand entfernt ist.

Diese 4 Koordinatenangaben verbindet der Browser dann zu einem viereckigen Verweis. Für meinen Adventskalender musste ich 24 Verweise erstellen. Der komplette HTML-Code sah am Ende dann so aus:

...

Die Datumsabfrage des Adventskalenders

Näheres über die Datumsabfrage des Adventskalenders mit PHP erfahrt ihr morgen im zweiten Teil.

Adventskalender erstellen – Teil 2: Die Datumsabfrage

Das Website Handbuch

Webseiten beschleunigen Teil 5 – Code optimieren

Webmaster — Sun, 31 Oct 2010 17:43:57 +0000

Im 5. und letzten Teil der Artikelreihe Webseiten beschleunigen will ich erklären, wie ihr den Code eurer Webseiten optimieren könnt. Die Möglichkeiten sind natürlich gerade bei HTML und CSS sehr begrenzt, da es sich ja nicht um Programmiersprachen sondern um eine Auszeichnungssprache (HTML) bzw. um eine Beschreibungssprache (CSS) handelt. Ein paar Tipps wie ihr euren Code optimieren und damit eure Webseiten beschleunigen könnt, kann ich euch aber trotzdem geben.

Reihenfolge von CSS und Javascript optimieren

Wenn ihr mit Page Speed eure Website überprüft, dann spuckt das Tool eventuell folgende Fehlermeldung aus:

Optimize the order of styles and scripts

Oder auf Deutsch: “Optimieren Sie die Reihenfolge der Stile und Skripte”. Mit styles (Stile) sind die CSS-Dateien gemeint und mit scripts (Skripte) Javascript-Dateien. Warum ist es nun wichtig, bei der Einbindung dieser Dateien auf die richtige Reihenfolge zu achten? Das liegt einfach daran, dass der Browser den HTML-Code erst verarbeiten kann, wenn er weiß, wie dieser formatiert wird. Deshalb ist es sinnvoll, die CSS-Dateien bereits im -Teil des HTML-Dokuments zu laden (alles andere wäre im übrigen auch nicht valide). Dann weiß der Browser wie die einzelnen HTML-Befehle dargestellt werden sollen und kann sofort damit beginnen.

Außerdem ist es wichtig, die Dateien zu gruppieren. Zuerst sollten alle CSS-Befehle im Code erscheinen und danach alle Javascript-Anweisungen. Gleichartige Dateien kann der Browser nämlich gleichzeitig herunterladen. Bei verschiedenen Dateitypen muss der Browser allerdings immer warten, bis ein Typ fertig geladen ist, bevor er mit dem nächsten beginnen kann. Eine richtige Einbindung von CSS- und Javascript-Befehlen sieht demnach so aus:

Dateien kombinieren

Sehr oft spuckt Page Speed auch eine der beiden folgenden Meldungen aus:

- Combine external JavaScript

- Combine external CSS

Damit weist das Tool daraufhin, dass es natürlich schneller ist, wenn ein Browser nur eine Datei übertragen muss, anstatt 2 oder sogar noch mehr. Generell ist es deshalb empfehlenswert, Javascript- und CSS-Dateien soweit wie möglich zusammenzufassen.

Allerdings gibt es auch Fälle, in denen das nicht unbedingt sinnvoll ist. Wenn ich z. B. auf Seite A nur einen einzigen Javascript-Befehl brauche, auf Seite B brauche ich aber mehrere und vielleicht sogar noch eine große JavaScript-Bibliothek wie z. B. jQuery, wäre eine Zusammenlegung kontraproduktiv.

Dateien minimieren

Um den Code übersichtlich und gut lesbar zu machen, werden in Javascript- und CSS-Dateien oftmals viele Zeichenumbrüche und Kommentare verwendet. Während der Entwicklung ist das sicher auch sinnvoll. Wenn der Code allerdings fertig ist, solltet ihr diesen überflüssigen Ballast entfernen. Darauf weisen die beiden Page Speed-Meldungen “Minify CSS” und “Minify JavaScript” hin. Bei großen JavaScript-Bibliotheken wie dem bereits angesprochenen jQuery gibt es meistens bereits eine minimierte (minified) Version. Außerdem bietet Page Speed sowohl für JavaScript als auch für CSS eine minimierte Version an, die ihr nur abspeichern und auf den eigenen Webspace hochladen müsst.

Page Speed bietet auch an, HTML-Dateien zu minimieren. Dies kann ich allerdings nicht empfehlen, da es bei mir bei einigen HTML-Dateien vorkam, dass sie danach nicht mehr richtig dargestellt wurden.

Grafiken richtig einbinden

Im ersten Teil dieser Serie habe ich ja beschrieben, wie ihr Grafiken verkleinern könnt, um Übertragungskapazität zu sparen. Um den Seitenaufbau zu beschleunigen ist aber nicht nur eine geringe Dateigröße der Grafik wichtig, sondern auch die richtige Einbindung in den HTML-Code. So sollte im img-Tag die Breite und Höhe einer Grafik angegeben werden, also z. B. so:

Wichtig dabei ist aber, dass die im img-Tag angegebenen Größen auch mit der tatsächlichen Bildgröße übereinstimmen. Ist das nicht der Fall, muss der Browser das Bild an die angegebenen Werte anpassen. Das hat 2 große Nachteile: Erstens kostet die Vergrößerung oder Verkleinerung einer Grafik sehr viele Ressourcen und verlangsamt dadurch den Seitenaufbau erheblich.

Und zweitens sind Browser dazu entwickelt worden, Webseiten dazustellen und nicht dazu, die Größe von Grafiken zu verändern. Deshalb sind die vom Browser veränderten Grafiken meistens unscharf und sehen nicht gut aus. Am einfachsten ist es, wenn ihr eure Bilder zuerst in einem Bildbearbeitungsprogramm wie paint.net oder gimp auf die richtige Größe bringt und sie erst danach in eure Webseite einbaut.

Webseiten beschleunigen

Damit ist die Artikelreihe “Webseiten beschleunigen” nun abgeschlossen. Wer all die gegebenen Tipps umsetzt, kann die Ladezeit seiner Webseiten erheblich verkürzen. Ich hatte bei meiner Rätselseite zu Beginn der Optimierung bei Page Speed einen Wert von ungefähr 80, den ich dann durch die von mir beschriebenen Optimierungs-Tipps auf 99 verbessern konnte. Durch den Einbau von Werbebannern, auf deren Code ich leider keinen Einfluss nehmen kann, ist der Wert zwar wieder gesunken, trotzdem hat sich die Ladezeit gegenüber dem Anfang erheblich verkürzt.

Eure Optimierungstipps

Habt ihr noch Fragen dazu, wie ihr eure Webseiten beschleunigen könnt? Liefert euch Page Speed vielleicht eine Meldung, die ihr nicht versteht? Oder habt ihr noch einige Tipps, wie der Aufbau von Webseiten beschleunigt werden kann? Dann schreibt doch bitte etwas in den Kommentaren dazu.

Artikelreihe Webseiten beschleunigen:

1. Dateigröße von Grafiken verkleinern

2. Expires-Header verwenden

3. Parallele Downloads

4. Die gzip-Compression

High Performance Websites

Webseiten richtig validieren

Webmaster — Sat, 18 Sep 2010 20:59:34 +0000

In dem Artikel Muss eine Webseite valide sein? habe ich gestern erklärt, was mit Validität gemeint ist, warum so viele Seiten im Internet nicht valide sind und welche Vorteile eine valide Webseite bietet. Im zweiten Artikel zum Thema Validieren geht es heute darum, wie ihr einfach eine valide Webseite erstellt, wie der W3C-Validator funktioniert und wie ihr die 10 häufigsten Validierungsfehler beheben könnt.

Grundgerüst für eine valide Webseite

Am einfachsten vermeidet ihr Validierungsfehler, wenn ihr euch ein HTML-Grundgerüst erstellt, das ihr als Vorlage für alle weiteren Seiten verwendet. Wenn dieses Grundgerüst ohne Fehler validiert wurde, treten bei darauf basierenden Webseiten normalerweise nur noch Flüchtigkeitsfehler auf. Ein minimales Grundgerüst, das ihr allerdings noch erweitern müsst, findet ihr z. B. bei SELFHTML.

Richtig validieren mit dem W3C-Validator

Der W3C-Validator ist recht einfach zu bedienen, bietet aber auch noch einige zusätzliche Optionen, mit denen ihr euch die Validierung eurer Webseite erleichtern könnt.

Die simpelste Möglichkeit die Validierung zu starten, ist auf der Startseite des W3C-Validators die URL der Webseite einzutragen, die ihr validieren möchtet. Wenn eure Webseite aber noch nicht online ist, könnt ihr unter “Validate by File Upload” auch einfach eine html-Datei zur Überprüfung hochladen. Bevorzugt ihr dagegen Copy & Paste, könnt ihr mit “Validate by Direct Input” den Quelltext in ein Fenster kopieren und auf diese Weise die Validierung starten.

Unter “More Options” solltet ihr bei “Show Source” noch einen Haken setzen. Dann könnt ihr mit einem Klick auf die Zeilennummer direkt in die entsprechende Zeile des Sourcecodes springen, der unterhalb der Fehlermeldungen eingeblendet wird.

Generell solltet ihr beim Validieren beachten, dass ihr die Fehler von oben nach unten korrigiert. Diese Reihenfolge ist deshalb so wichtig, weil viele Fehler Folgefehler aus anderen Fehlern sind. Es kann durchaus sein, dass z. B. 10 Fehler angezeigt werden, es sich in aber Wirklichkeit nur um einen Fehler handelt. Am besten startet ihr die Validierung nach jeder Fehlerkorrektur neu, damit ihr seht, welche Fehler danach noch vorhanden sind.

Erfolgsmeldung des W3C-Validators nach dem Validieren

Häufige Fehlermeldungen des W3C-Validators

Die folgenden 10 Fehlermeldungen treten sehr oft beim Validieren auf:

character “&” is the first character of a delimiter but occurred as data

Diese Meldung bedeutet, dass der Validator ein Zeichen gefunden hat, das er nicht versteht. Dabei kann es sich um einen Umlaut, ein “ß” oder um ein anderes Sonderzeichen handeln. Diese Zeichen müssen dann “maskiert” werden, d. h. sie müssen so kodiert werden, dass sie der Browser versteht. Eine gute Übersicht über das Maskieren von Sonderzeichen gibt es z. B. bei SELFHTML. Ein Generator zum Erzeugen der richtigen Kodierung findet ihr bei Leftlogic.

required attribute “alt” not specified

Diese Fehlermeldung tritt auf, wenn ihr eine Grafik mit dem -Tag anzeigen lässt, aber keinen Alternativ-Text angegeben hat. Dieser sollte eine Beschreibung des Bildes beinhalten und ist z. B. für Blinde wichtig, die die Grafik ja nicht sehen können und deshalb auf diesen Alternativ-Text angewiesen sind. Bei reinen Ziergrafiken solltet ihr keinen Text angeben, also so: alt=”". Weitere Tipps dazu findet ihr wieder bei SELFHTML.

end tag for element “A” which is not open

Das bedeutet, dass ihr einen Tag geschlossen habt, den ihr nicht geöffnet hattet. Oder anders herum gesagt, entweder habt ihr den öffnenden Tag wie z. B. vergessen oder ihr habt einen schließenden Tag wie z. B. zuviel gesetzt.

end tag for “div” omitted, but OMITTAG NO was specified

Diese Meldung ist das Gegenstück zu der vorhergehenden Fehlermeldung. Hier bemängelt der Validator, dass es zwar einen Start-Tag, aber keinen End-Tag gibt. Entweder habt ihr einen Start-Tag doppelt oder was häufiger vorkommt, den End-Tag vergessen.

required attribute “TYPE” not specified

Diese Fehlermeldung erscheint z. B. wenn ihr eine Javascript-Datei in euren Quelltext einbindet und vergessen habt, den Typ anzugeben. Eine Javascript-Datei wird so eingebunden:

there is no attribute “WIDTH”

Diese Meldung wird ausgegeben, wenn ihr ein Attribut benutzt, das von dem jeweiligen Tag nicht unterstützt wird. Eine Übersicht der zulässigen Attribute findet ihr bei SELFHTML.

document type does not allow element “body” here

Dieser Fehler kann angezeigt werden, wenn ihr ein Element an der falschen Stelle im Quelltext verwendet, z. B. das Element bevor ihr den Seitenkopf mit abgeschlossen habt.

character “<” is the first character of a delimiter but occurred as data

Diese Fehlermeldung erscheint z. B. wenn ihr vergessen habt, einen Tag mit einem “>” zu schließen, also z. B. so:

`literal is missing closing delimiter`

Diese Meldung wird ausgegeben, wenn ihr z. B. bei einer Pfadangabe das abschließende Anführungszeichen vergessen habt, also so:

Browsershots verwenden. Dieser erstellt Screenshots eurer Webseite unter verschiedenen Browsern und Betriebssystemen. Wenn dort alles so aussieht, wie ihr es geplant habt, dann könnt ihr sicher sein, dass eure Webseite überall richtig angezeigt wird.

`Validiert ihr eure Webseiten?`

Wie geht ihr beim Erstellen von Webseiten vor? Validiert ihr diese oder ist es euch egal, wenn ihr eine Webseite mit vielen Fehlern habt? Schreibt doch bitte in den Kommentaren etwas dazu.

Muss eine Webseite valide sein?

Das Website Handbuch: Programmierung und Design



Muss eine Webseite valide sein?
Webmaster — Fri, 17 Sep 2010 17:27:36 +0000
In vielen Webmaster-Foren wird bei der Bewertung von Webseiten Wert darauf gelegt, dass diese valide sind. Doch wie wichtig ist eigentlich die Validität einer Webseite? Hat man durch eine valide Webseite Vorteile bei Google? Warum gibt es im Internet so wenige valide Seiten? Diese und andere Fragen versuche ich in diesem Artikel zu beantworten.
Was bedeutet Validität überhaupt?
Validität in Bezug auf Webseiten bedeutet, dass eine Webseite die Standards, die das W3C festgelegt hat, einhält. Dieses Gremium wurde gegründet von Tim Berners-Lee, der als Erfinder des WWW und als Vater von HTML gilt. Das W3C bietet auf einer Webseite einen Validator an, mit dem man die Validität (Gültigkeit) einer Webseite überprüfen kann. Wenn dieser Test fehlerfrei durchlaufen wird, gilt eine Webseite als valide.
Welche Vorteile hat eine valide Webseite?
Eine Webseite, die valide ist, also die Standards des W3C einhält, soll in allen Browsern fehlerfrei angezeigt werden. Leider ist das aber nur graue Theorie. Denn selbst eine völlig fehlerfreie Webseite wird von manchen Browsern nicht richtig angezeigt. Besonders negativ zeichnet sich hier oftmals der Internet Explorer aus, der die W3C-Standards nicht alle richtig umsetzt.
Aber trotzdem ist es sinnvoll, eine Webseite valide zu machen. Denn bei einer validen Webseite sind nur wenige Anpassungen notwendig, damit sie in allen aktuellen Browsern richtig angezeigt wird. Zumal man bei einer Seite, die nicht valide ist, nie sicher sein kann, wie sie angezeigt wird. Außerdem kann man bei nicht validem Code nie sicher sein, wie lange er richtig angezeigt wird. Hält sich eine Webseite dagegen an die W3C-Standards kann man dagegen davon ausgehen, dass sie auch in einigen Jahren noch richtig angezeigt wird.
Warum sind so viele Seiten im Internet nicht valide?
Der Grund, warum so viele Webseiten nicht valide sind, liegt darin, dass die meisten Browser den HTML-Code einer Webseite sehr großzügig auslegen. Oftmals wird z. B. von dem Ersteller einer Webseite das schließende Tag weg gelassen. Solche Fehler korrigieren die meisten Browser automatisch. Für den Ersteller der Webseite ist das natürlich praktisch. Im Gegensatz zu einer Programmiersprache wie PHP erscheint bei HTML keine Fehlermeldung und die Seite wird trotzdem oftmals richtig dargestellt. Zumindest in dem Browser, den der Entwickler zum Testen der Webseite benutzt. In anderen Browsern kann das aber, wie bereits erwähnt, wieder anders aussehen.
Ein weiterer Grund, warum viele Webseiten nicht valide sind, liegt in der Einbindung von fremden Code-Fragmenten. Wer z. B. Werbung auf seiner Webseite eingebunden hat, kriegt oftmals einen Javascript-Code geliefert, der für die Einblendung der Werbung zuständig ist. Ist dieser nicht sorgfältig programmiert, wird die Werbung zwar richtig angezeigt, die Seite ist aber nicht mehr valide. Das gleiche gilt z. B. auch für schlampig programmierte Wordpress-Plugins, die auch Validierungsfehler erzeugen können.
Auch Homepage-Baukästen, die von manchen Hostern angeboten werden und schlecht programmierte HTML-Editoren (einen besonders schlechten Ruf genießt in dieser Hinsicht Frontpage) erzeugen oftmals nicht validen Code.
Wieso ist die Google-Seite nicht valide?
Wenn man die Google-Webseite vom W3C-Validator überprüfen lässt, werden zur Zeit 37 Fehler angezeigt. Eigentlich sollte man doch gerade bei Google erwarten können, dass sie eine valide Webseite erzeugen können. Warum ist das dann trotzdem nicht der Fall? Die Antwort darauf ist, dass es sich dabei um Absicht handelt. Die Google-Seite wird jeden Tag unzählige Male aufgerufen. Da zählt jedes Byte, das zuviel übertragen wird. Durch das Weglassen von schließenden Tags wie z. B.  und  läßt sich einfach Speicherplatz einsparen. Für Google ist nun mal die Größe einer Webseite und die Anzeigegeschwindigkeit wichtiger als die Einhaltung der W3C-Standards.
Nicht valide Google-Webseite
Ist eine valide Webseite für das Google-Ranking wichtig?
Die Antwort auf diese Frage ist umstritten. In einem Interview aus dem Jahre 2008, das von bloggonaut.net auf Deutsch zusammengefasst wurde, sagt der Google-Mitarbeiter Matt Cutts, dass die Einhaltung von Webstandards in keinster Weise das Ranking einer Webseite verbessert (Punkt 19). Dafür spricht auch, dass man unter den großen Webseiten (z. B. tagesschau.de, spiegel.de) selten eine finden wird, die valide ist. Wenn eine Seite allerdings so viele Validierungsfehler hat, dass die Suchmaschinen Schwierigkeiten haben, sie richtig zu interpretieren, könnte das schon eine Rolle beim Ranking spielen.
Wie kann man eine valide Webseite erstellen?
Dass eine Webseite, die sich an die W3C-Standards hält, einige Vorteile bietet, habe ich in diesem Artikel geschildert. Wie ihr eine valide Seite erstellt und wie ihr die häufigsten Validator-Fehlern korrigiert, das erfahrt ihr in dem zweiten Artikel zu diesem Thema, der morgen erscheint.
Webseiten richtig validieren
HTML & XHTML – kurz & gut
 


Reflinks kennzeichnen
Webmaster — Wed, 14 Jul 2010 05:31:51 +0000
Ein Reflink ist ein Link, der meist auf einen Shop oder eine andere kommerzielle Seite verweist. Wenn ein User auf einen Reflink klickt und danach in dem Shop etwas kauft, kriegt derjenige, der den Link gepostet hat, eine Provision von dem Händler ausbezahlt. Wenn ihr jetzt z. B. auf diesen Link hier klickt -> Amazon, dann landet ihr bei Amazon und kriegt ein Buch zum Thema CSS angezeigt. Kauft ihr danach dieses Buch oder einen anderen Artikel bei Amazon, dann kriege ich eine Provision für diesen Kauf.
Das ist eigentlich eine faire Sache, von der alle profitieren. Ich empfehle dem Käufer einen Artikel, den er wahrscheinlich noch nicht gekannt hat und kriege als Gegenleistung dafür eine kleine Provision. Und Amazon profitiert natürlich auch davon, weil durch meine Empfehlung zusätzlicher Umsatz generiert wird.
Fair geht vor
Wichtig ist aber, dass, wenn man einen solchen Reflink in seinen Blog einbaut (und das sollte man auch wirklich nur auf der eigenen Seite tun), man seinen Besuchern gegenüber so fair ist und diesen kennzeichnet. Wie das funktioniert, erkläre ich in diesem Artikel.
Reflinks mit dem Euro-Symbol kennzeichnen
Um einen Reflink zu kennzeichnen, empfiehlt es sich auf das CSS-Pseudoelement “:after” zurückzugreifen. Damit kann man nach einem Element noch einen Text oder eine Grafik einbauen. Nach dem :after weist man dann der Eigenschaft “content” den gewünschten Inhalt zu. Wenn man hinter einem reflink ein rotes Euro-Zeichen einblenden will, sieht der Code dafür wie folgt aus:
a.reflink:after{content:" €"; color:red;}
Zuerst kommt das Element dem man einen Inhalt anhängen will. Das ist in diesem Beispiel ein Link, also ein a. Dahinter kommt die Klasse, die wir nachher in den HTML-Code einbauen. Ich habe sie in diesem Fall “reflink” genannt. Dann folgt das schon angesprochene Pseudoelement “:after”. In der geschweiften Klammer gibt man hinter “content:” den Inhalt an, der hinzugefügt werden soll. Im Beispiel füge ich ein Leerzeichen und ein Eurozeichen hinzu. Diesen Inhalt kann man dann noch nach Wunsch formatieren. Mit “color:red” habe ich die Schrift für das Eurozeichen auf rot geändert.
Wenn man, so wie ich im Beispiel, Sonderzeichen anhängen will, sollte man darauf achten, dass man die CSS-Datei als “UTF-8 ohne BOM” speichert. Das geht am einfachsten, wenn man die CSS-Datei mit Notepad++ erstellt und dort unter “Kodierung” das entsprechende Format wählt.
Reflinks mit einer Grafik kennzeichnen
Will man anstatt eines Textes eine Grafik anhängen, dann sieht der CSS-Code wie folgt aus:
a.reflink:after{content:url(http://example.com/grafik.png);}
Wenn man, wie im ersten Beispiel, noch ein Leerzeichen hinter dem Element haben will, sieht es so aus:
a.reflink:after{content: " " url(http://example.com/grafik.png);}
Zum Schluss braucht man nur noch die Klasse in den HTML-Code einzubauen:
Alternativ zu “:after” kann man auch das Pseudoelement “:before” verwenden. Dieses bewirkt, dass der Inhalt vor dem Element ausgegeben und nicht dahinter wie bei “:after”.
Einen kleinen Nachteil haben “:after” und “:before” allerdings. Der Internet Explorer unterstützt diese beiden Pseudoelemente erst ab Version 8. Von älteren Versionen des IE werden sie daher ignoriert.
Reflinks in euren Blogs
Verwendet ihr auch Reflinks in euren Blogs? Und falls ja, kennzeichnet ihr diese? Ich würde mich freuen, wenn ihr eure Erfahrungen dazu in den Kommentaren posten würdet.
Die heimlichen Internet-Gewinner
 


Print.css für Webseiten erstellen
Webmaster — Sat, 22 May 2010 23:33:12 +0000
“Denn was man schwarz auf weiß besitzt, kann man getrost nach Hause tragen.” Im Zeitalter von Terabyte-Festplatten, Online-Webspace und Netbooks mit WLAN mag dieser Satz, den Goethe vor über 200 Jahren seinem Faust in den Mund gelegt hat, etwas anachronistisch klingen. Wer druckt heute noch Informationen aus, auf die man ganz leicht online zugreifen kann?
Nun ja, ein paar Leute gibt es schon noch, die keinen Internetzugang haben und sich über einen Ausdruck freuen. Und lange Artikel lesen sich auf Papier einfach besser als auf dem Monitor. Auch bei Anleitungen ist es praktischer, wenn man sie ausgedruckt vor sich liegen hat, anstatt ständig von einem Tab zum anderen wechseln zu müssen.
Screenshot-Tools sind kein Ersatz für eine print.css
Andererseits ist es auch verständlich, dass viele Leute eine gewisse Scheu davor haben, Webseiten auszudrucken. Viele Webmaster kommen nämlich gar nicht auf die Idee, eine Druckversion ihrer Webseiten zu erstellen. Schließlich können die User sich ja auch mit einem Screenshotprogramm die Inhalte der Website ausdrucken.
Das ist allerdings ein wenig zu kurz gedacht, denn so praktisch ein solches Tool in vielen Fällen sein kann, zum Ausdrucken von Webseiten ist es eigentlich nicht gedacht. So wird zum Beispiel die Hintergrundfarbe mit ausgedruckt, was bei den hohen Preisen, die man für eine Tintenpatrone zahlen muss, wohl eher selten erwünscht ist.
Eine print.css in die Webseite einbinden
Eine Druckversion einer Webseite zu erstellen macht also schon Sinn und es ist auch gar nicht so schwierig, wie man im ersten Moment vielleicht glauben könnte. Am einfachsten ist es, wenn man eine eigene CSS-Datei nur für den Ausdruck erstellt und diese in alle Webseiten integriert. Normalerweise bindet man eine CSS-Datei ja so ein:
Wenn man die CSS-Datei so aufruft, wird sie für alle möglichen Zwecke genutzt, also auch für’s Drucken. Da wir dafür aber eine eigene CSS-Datei erstellen wollen, ist es wichtig, dem Browser zu sagen, dass er die bisherige CSS-Datei nur für die Monitordarstellung nutzen soll. Dafür setzen wir das media-Attribut auf “screen”:
Und bei Bei unserer CSS-Datei, die wir für den Druck nutzen wollen, setzen wir das media-Attribut auf “print”:
Wenn wir diese beiden Zeilen in eine Webseite einbinden, verwendet der Browser automatisch die richtige Version, abhängig davon, ob sie auf dem Monitor angezeigt oder ausgedruckt werden soll.
Was schreiben wir nun in unsere print.css rein (der Dateiname kann übrigens beliebig gewählt werden)?
Die passende Schrift für eine print.css
Zuerst ist es mal wichtig, dass wir die Schriftart ändern. Während auf dem Monitor serifenlose Schriften besser zu lesen sind, werden diese beim Druck nur für die Überschriften verwendet und beim normalen Fließtext greift man auf Schriften mit Serifen zurück. Für eine bessere Lesbarkeit empfiehlt es sich, die Schriftfarbe auf Schwarz zu setzen. Die Schriftgröße sollte man in pt angeben.
body {font-family:Georgia,Times,serif;font-size:11pt;color:black;}
 h1,h2,h3 {font-family:Verdana,Helvetica,sans-serif;text-align:center;}
 h1 {font-size:22pt;}
 h2 {font-size:16pt;padding-top:6pt;}
Bei der Überschrift h2 habe ich hier noch ein padding-top eingebaut, um einen Abstand zum vorhergehenden Text zu erzeugen. Und mit “text-align:center” werden die ersten 3 Überschriftsebenen automatisch zentriert.
Wer möchte, kann mit “background-color:#fff” auch noch die Hintergrundfarbe auf weiß setzen. Bei modernen Browsern ist das aber eigentlich nicht notwendig, da bei diesen der Hintergrund standardmäßig nicht mitgedruckt wird.
Überflüssige Inhalte nicht ausdrucken
Wie ich bereits weiter oben angesprochen habe, gibt es bestimmte Inhalte einer Website, auf die man beim Druck verzichten kann. Dazu zählen z. B. das Logo, die Navigation, die Werbung, Formulare, Ziergrafiken und der Footer. Am einfachsten ist es, wenn man diesen Inhalten eine eigene Klasse zuweist (z. B. mit class=”noprint”) und sie dann für den Druck ausschließt:
.noprint {display:none;}
Bilder und Links zentrieren
Bei Fotos und Bildern ist es sinnvoll, diese zu zentrieren:
img{display:block;margin:0 auto;}
Links braucht man eigentlich nicht besonders zu kennzeichnen, da sie auf dem Papier ja keinen Nutzen haben. Deshalb ist es sinnvoll, sie als normalen Text darzustellen:
a{color:black;text-decoration:none;}
Wer möchte, kann aber auch hinter jedem Link die Linkadresse anzeigen lassen:
a[href]:after {content:" [Link: "attr(href)"] ";}
Diese Form der Ausgabe wird allerdings nicht vom Internet Explorer unterstützt. Außerdem erschwert sie bei vielen Links auf der Webseite das Lesen, weshalb ich persönlich diesen Code nicht verwende.
Die fertige print.css
Das war’s auch schon. Am Ende kann unsere print.css dann z. B. so aussehen:
body {font-family:Georgia,Times,serif;font-size:11pt;color:black;}
 h1,h2,h3 {font-family:Verdana,Helvetica,sans-serif;text-align:center;}
 h1 {font-size:22pt;}
 h2 {font-size:16pt;padding-top:6pt;}
 .noprint {display:none;}
 img{display:block;margin:0 auto;}
 a{color:black;text-decoration:none;}
Mit nur sieben Zeilen Code haben wir eine print.css erstellt, die eine saubere Druckversion unserer Webseite darstellt. Den Unterschied sieht man deutlich:
Ausdruck einer Website ohne eine print.css
Ausdruck einer Website mit einer print.css
Ohne die Verwendung einer print.css werden für den Druck 2 Seiten benötigt, da die Navigation auf einem extra Blatt ausgedruckt wird und durch die Anzeige von weiteren überflüssigen Elementen wirkt der Ausdruck ziemlich unübersichtlich. Die zweite Variante, die auf eine angepasste print.css zurückgreift, konzentriert sich dagegen auf das Wichtige und zeigt die Website dadurch wesentlich übersichtlicher an.
Verwendet ihr eine print.css?
Wie sieht es bei euch aus? Stellt ihr euren Besuchern eine Druckversion zur Verfügung und falls ja, wie sieht diese aus? Wie immer würde ich mich freuen, wenn ihr in den Kommentaren etwas dazu schreibt.
Little Boxes