Um DIVs mit einer festen Breite horizontal zu zentrieren, kann man sie entweder absolut positionieren oder eine negative Marge setzen. Alternativ, kann man auch solche DIVs mit fester Breite zentrieren indem man beide ihre linke und rechte Marge auf „auto“ setzt. Der Browser wird dann beiden Margen dieselbe breite vergeben.
Leider funktionieren beide Varianten oben bei DIVs mit einer variablen Breite nicht. Für solche Fällen wird eine andere Lösung gebraucht.
Angenommen, man hat einen äußeren DIV der einen anderen DIV enthält:
Der äußere DIV wird das ganze Fenster füllen und der innere DIV die obere linke Ecke:
Der Trick um den inneren DIV zu zentrieren, ist die Text-Ausrichtung beim äußeren DIV auf zentriert zu setzen während die Display-Eigenschaft vom inneren DIV auf inline-block gesetzt wird. Natürlich wird die Text-Ausrichtung vom äußeren DIV auch vom inneren DIV geerbt. Deswegen muss sie beim inneren DIV zurückgesetzt werden:
Diese Technik ist eine gute Alternative zur JavaScript-Lösung, wo man die Breite vom DIV ermittelt und die Margen entsprechend setzt. Falls Sie trotzdem Interesse an der jQuery-Lösung, siehe das Blog von Manos Malihutsakis.
Wir haben gerade ein neues Tool zum automatischen Maskieren von HTML-Steuerzeichen. Das Tool ist nützlich, wenn man in einem HTML Tag bzw. Attribut Text schreiben kann, das Zeichen enthält die maskiert werden müssen. Hier ein paar Beispiele dafür:
& –> &
ä –> ä
ß –> ß
“ –> "
‚ –> '
Das Tool enthält zwei Text-Widgets. Im ersten Widget kann man den zu konvertierenden Text schreiben (man kann auch durch Copy&Paste Text einfügen). Es wird automatisch im zweiten Text-Widget als maskierter Text angezeigt. Der konvertierte Text wird bei jeder Änderung vom zu konvertierenden Text aktualisiert.
Man kann dann den konvertierten Text kopieren und an Stelle vom ursprünglichen Text verwenden. Alternativ kann man auch auf dem Knopf „In die Zwischenablage kopieren“ klicken.
Es gibt in HTML5 zwei neue Tags, die noch weniger bekannt aber sehr nützlich sind: die Details und Summary Tags. Mit diesen neuen Tags kann man einige lange Inhalte verstecken und nur eine Zusammenfassung zeigen bis der Benutzer die Details einblendet. Es wird zum Beispiel oft bei Produktbeschreibungen verwendet.
Solche Elemente kann man schon lang mit JavaScript bzw. jQuery implementieren. Hier ein Beispiel mit jQuery:
Zuerst der HTML-Code: Wir haben zwei Details-Div-Tags mit jeweils einen Summary-Div-Tag und zwei Absätze, die die eigentliche Details enthalten.
Wenn man auf einem Summary-Div-Tag klickt, muss die Absätze im selben Details-Div-Tag ein- bzw. ausgeblendet werden. Am Anfang sollen diese Absätze alle ausgeblendet werden.
Das man mann alles mit ein paar Zeilen jQuery-Code:
Und wenn man auch will, dass Plus-Zeichen durch ein Minus-Zeichen ersetzt wird, wenn die Details offen sind:
details[open] summary:after {
content: "-";
}
Leider werden diese zwei neue Tags nicht von allen Browser unterstützt. Zur Zeit gibt es kein Support in Internet-Explorer, Firefox und Opera-Mini. Die Unterstützung in mobilen Browsers ist somit schon gesichert.
Wer auch Desktop-Browsers unterstützen will aber trotzdem nicht auf diese zwei Tags verzichten will, verwendet den jQuery-Plugin jquery-details. Man muss einfach die Datei anbinden und folgendes ausführen:
$('details').details();
Der Plugin wird somit den Browser-Support ermitteln und, wenn notwendig, die neue Tags mit jQuery anpassen.
Man kann auch dasselbe mit Details-Polyfill, jquery.details, Element.details or jquery-deets erreichen. Es fehlt also nicht an Möglichkeiten diese neue Tags einzusetzen und trotzdem eine Ausweichlösung für Browsers zu haben, die sie noch nicht unterstützen.
Google hat einen neuen Panda-Update (also Nummer 24) angekündigt.
Diese Aktualisierung betrifft laut Google ca. 1,2% der englischen Suchabfragen (bzw. deren Suchergebnisse).
Das letzte Panda-Update (also Nummer 23) ist ca. 1 Monat alt und wurde am 21 und hat ca. 0,8% der Suchanfragen betroffen. Dezember ausgerollt. Seit Februar 2011 werden ca. 1 Mal pro Monat neue Panda-Aktualisierungen ausgerollt, mit dem Ziel die Suchergebnisse weiter an dem Inhalt der Seiten zu orientieren und so hochwertigere Suchergebnisse zu liefern. Es macht natürlich das Leben schwer für SEO-Firmen rund um den Globus.
Google gibt auch im offiziellen Google Webmaster Central Blog Tipps wie man hochwertigere Seiten baut und so trotz Panda gute Platzierungen in den Suchergebnisse erreichen kann.
Man kann diese Empfehlungen in folgenden Kategorien aufteilen:
Vertrauen des Inhaltes, der Seite bzw. des Autors.
Keine Duplizierung des Inhaltes (mit z.B. leicht andere Schlüsselwörter). Da geht es auch darum eine Mehrwert gegenüber ähnliche andere Seiten zu liefern (was natürlich auch nur geht, wenn man nicht nur 2 Zeilen zum Thema schreibt).
Genauigkeit des Inhaltes (z.B. auch Rechtschreibung).
Gleichgewicht zwischen Inhalte und Werbeflächen.
Viele diesen Ratschlägen sind natürlich offensichtlich. Google wird auch nicht Hinweise geben, wie man einfach solche Algorithmus-Anpassungen umgehen kann, mit dem Ziel nicht hochwertige Inhalt nach oben zu pushen.
Wenn man die Inhalt einer Webseite optimiert muss man auch nicht vergessen, dass die Qualität der einzelnen Seiten auch einen Einfluss auf der von Google wahrgenommene Qualität aller Seiten der Domäne.
Als Websitebesitzer, die möglicherweise am schlimmsten Erfahrung für Ihre Besucher fängt mit einer frustrierenden Wartezeit an, während die Sanduhr sich dreht und die Seite langsam geladen wird. Viele Ihrer Besucher (und daher potentiellen Kunden) werden dann gleich abspringen d.h. die Seite sofort verlassen z.B. in dem sie den Zurück-Knopf verwenden.
Die Website-Geschwindigkeit wird auch schon in Googles Algorithmen berücksichtigt und wird weiter in der Zukunft eine Rolle spielen.
Wenn Ihre Website also benutzerfreundlich und bei den Suchmaschinen gut positioniert sein soll, dann werden Sie nach Möglichkeiten suchen, um die Ladezeiten Ihrer Webseite zu verbessern. Es gibt Vielzahl von Möglichkeiten eine Webseite schneller zu machen. Einer der einfachsten Techniken, um Webseiten zu beschleunigen, ist die Verwendung von CSS Bild-Sprites.
Diese Technik wird sowohl von Yahoo! als auch von Google empfohlen.
Wenn eine Webseite viele Bilder enthält, kann es dazu führen, dass die Seite eine lange Zeit zum Laden braucht und dabei mehrere Server-Abfragen erzeugt. Mit Bild-Sprites verringert sich die Anzahl der Server-Abfragen und Bandbreite wird gespart.
Wenn man zum Beispiel diese 4 Icons anzeigen will, damit die Besucher per Email, Facebook, Twitter oder Reddit die Seite sharen können:
Der Code würde so aussehen:
Um diese 4 Icons anzuzeigen, werden 4 Anfragen zum Server geschickt, um die einzelne Bilder zu laden. Es wäre effizienter alle Bilder mit einer Anfrage zu laden. Dafür muss man zuerst ein Bild erzeugen, das diese 4 Bilder enthält.
Unter Linux lässt es sich ganz einfach mit imagemagick aus der Kommandozeile machen:
cd mein_upload_verzeichnis
convert mail_app.png facebook.png twitter.png reddit.png -append social-sprite.png
Das Ergebnis sieht so aus:
ImageMagik kann auch unter Mac OS X installiert werden:
Mit MacPorts:
$ sudo port install ImageMagick
Mit Homebrew:
$ brew install ImageMagick
Ein Installer für Mac OS X gibt es auch bei Cactuslab
Es wird also immer die selbe Datei referenziert und die CSS background-position -Eigenschaft wird dann verwendet um dem Browser mitzuteilen, wo das Bild im enthaltenden Elements zu positionieren ist.
Die Koordinaten sind also negative Zahlen, weil es nicht definiert wird, wo man auf dem Bild sich positioniert, vor man 32 x 32 Pixel lies, sondern es wird definiert, dass das Bild erst nach oben 32, 64 bzw. 96 Pixel rutschen soll, vor man auf Position (0, 0) 32 Pixel liest.
Es ist natürlich mehr Arbeit, die Bilder so zu definieren aber es lohnt sich, besonders wenn man viele Icons verwendet.
In diesem Beispiel hatten wir ohne Sprites: 4 HTTP-Aufrufe / 14 KB an Bilder geladen.
Mit Sprites: 1 HTTP-Aufruf (also -75%) / 8 KB geladen (also -42%).
Natürlich kann man auch meinen, dass es keine besonders elegante Lösung das Hintergrund-Bild von einem div Element zu verwenden (nach dem Motto: Ein Bild sollte als ein img Element kodiert werden). Es kommt auch dazu, dass die Verwendung von Hintergrundbilder oft schlecht für Accessability sind. Zum Glück kann man es auch mit einem img Tag tun:
CSS Sprites sollte nur für dekorative Elemente verwendet werden. Aus diesem Grund sollte man img Tags für Elemente, die spezifisch für eine Seite sind verwenden und Sprites für dekorative Elemente, die nicht kontextuell relevant verwenden. Es macht Sinn ein CSS-Sprite mit Bild als Hintergrund für einen Knopf im Navigationssystem zu haben (weil es auch redundant zur Bildinformation auch Textinhalt gibt).
Man sollte auch beachten, dass die Performance-Verbesserung mit Sprites nicht mehr so beeindruckend ist, wenn man bedenkt, dass Browsern die Bilder im Cache zwischenspeichern und sie nicht jedes Mal geladen werden müssen. Es ist natürlich nur für wiederkehrende Besucher der Fall.
Ein Problem bei der Verwendung von CSS-Sprites ist die Speichernutzung. Ein komprimiertes Bild, das 20 Kilobyte groß ist, kann schnell über 50 MB Gross werden. Wenn man große Sprites mit vielen Bilder verwendet, kann es ein Problem werden.
Update vom 20. Dezember 2012: Der Widget unten wird demnächst als WordPress-Plugin freigegeben, damit man nicht immer den Code im Theme selber einbauen muss.
Mit einer Schlagwortwolke (Tag-Cloud) kann man sehr einfach eine Liste von Schlagwörtern kompakt und übersichtlich darstellen. Hier ein Beispiel aus unserer Webseite:
Man kann mit folgender Funktion eine Schlagwortwolke programmatisch anzeigen:
Zusätzlich zu diesen Parameter kann man auch exclude verwenden, um bestimmte Tags auszuschließen. Umgekehrt mit include kann man eine Liste von Tags definieren, die angezeigt werden sollen.
Wenn man aber einen Bereich hat, wo man nur ein Teil der Artikel sehen kann d.h. nur eine oder mehrere Kategorien, macht es Sinn in der Tag-Cloud nur die Tags anzuzeigen, womit Artikel aus dieser Kategorie bzw. aus diesen Kategorien markiert wurden. Die include Option von wp_tag_cloud zu verwenden ist keine gute Lösung, da man die Liste dann ständig erweitern muss. Am besten wäre es, wenn man einfach eine Liste von Kategorien definieren könnte, die berücksichtigt werden müssen. Das kann man leider mit dem Tag-Cloud-Widget in WordPress nicht erreichen. Aber kann mit dem hier vorgestellten Widget gemacht werden.
Man kann den Titel des Widgets konfigurieren und auch eine oder mehrere Kategoriene aus der Liste aller Kategorien wählen:
Es werden dann alle Tags angezeigt, womit Artikel in einer dieser Kategorien markiert wurden. Ein Beispiel davon kann man hier rechts sehen.
Hier der Code zum Widget:
'widget_cat_tag_cloud', 'description' => __( "Tag cloud for a specific category") );
$this->WP_Widget('cat_tag_cloud', __('aw - "Category Tag Cloud"'), $widget_ops);
}
function widget($args, $instance) {
extract($args);
global $wpdb;
$title = apply_filters('widget_title', empty($instance['title']) ? '' : $instance['title'], $instance, $this->id_base);
$tags = $wpdb->get_results
("
SELECT DISTINCT tt2.term_id AS tag_id
FROM wp_posts as posts
INNER JOIN wp_term_relationships as tr1 ON posts.ID = tr1.object_ID
INNER JOIN wp_term_taxonomy as tt1 ON tr1.term_taxonomy_id = tt1.term_taxonomy_id
INNER JOIN wp_term_relationships as tr2 ON posts.ID = tr2.object_ID
INNER JOIN wp_term_taxonomy as tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id
WHERE tt1.taxonomy = 'category'
AND posts.post_status = 'publish'
AND tt1.term_id IN (".implode(",",$instance['category_id']).") AND
tt2.taxonomy = 'post_tag'
");
foreach ($tags as $tag) {
$includeTags = $tag->tag_id .',' . $includeTags;
}
$cloud_args = array('include'=>$includeTags);
echo $before_widget;
if ( $title ) echo $before_title . $title . $after_title;
?>
Wenn der Widget oben in der Datei aw-widgets.php im Theme gespeichert wurde, kann man den Widget im Theme aktivieren, in dem man folgendes in functions.php einfügt:
include_once('aw-widgets.php');
Der Widget macht folgendes:
Es wird eine Liste von Kategorie-IDs im Widget definiert. Der Widget führt dann eine SQL-Abfrage, um eine Liste von relevanten Tags zu bekommen. Der WordPress 3 Modell sieht so aus:
Die relevante Tabellen haben eine blaue Kopfzeile.
Beide Kategorien und Tags sind Terms. Sie sind also in der Tabelle wp_terms gespeichert und werden durch eine term_id identifiziert. Ob es sich um eine Kategorie oder einen Tag wird mit der Zuweisung einer Taxonomie definiert. Es geschieht, wenn die term_id in der wp_term_taxonomy Tabelle referenziert wird. Wenn man nur mit der term_id arbeitet, braucht man also die wp_terms Tabelle nicht, dann reicht nämlich die wp_term_taxonomy Tabelle.
Um alle Tags zu holen, kann man folgende SQL-Abfrage ausführen:
SELECT DISTINCT tt.term_id AS tag_id
FROM wp_term_taxonomy as tt
WHERE tt2.taxonomy = 'post_tag'
Ähnlich kann man die Kategorien holen:
SELECT DISTINCT tt.term_id AS category_id
FROM wp_term_taxonomy as tt
WHERE tt2.taxonomy = 'category'
Wenn man jetzt nach Tags die zu einem Artikel gehören, muss man die wp_term_taxonomy Tabelle mir der wp_posts Tabelle verbinden. Man kann sie nicht direkt sondern über die wp_term_relationships Tabelle verbinden.
SELECT DISTINCT posts.ID
FROM wp_posts as posts
INNER JOIN wp_term_relationships as tr ON posts.ID = tr.object_ID
INNER JOIN wp_term_taxonomy as tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
WHERE tt.taxonomy = 'category'
AND posts.post_status = 'publish'
AND tt.term_id IN (xxx, yyy, zzz)
Man bekommt so eine Liste von allen Posts in einer diesen 3 Kategorien. Jetzt muss man nur noch die Tags für diesen Artikel finden:
SELECT DISTINCT tt.term_id AS tag_id
FROM wp_posts as posts
INNER JOIN wp_term_relationships as tr ON posts.ID = tr.object_ID
INNER JOIN wp_term_taxonomy as tt ON tr.term_taxonomy_id = tt.term_taxonomy_id
WHERE tt.taxonomy = 'post_tag'
AND posts.post_status = 'publish'
AND posts.ID IN (xxx, yyy, zzz)
Man bekommt so alle Tags für diese 3 Posts. Wenn man jetzt beide Abfragen kombiniert:
SELECT DISTINCT tt2.term_id AS tag_id
FROM wp_posts as posts
INNER JOIN wp_term_relationships as tr1 ON posts.ID = tr1.object_ID
INNER JOIN wp_term_taxonomy as tt1 ON tr1.term_taxonomy_id = tt1.term_taxonomy_id
INNER JOIN wp_term_relationships as tr2 ON posts.ID = tr2.object_ID
INNER JOIN wp_term_taxonomy as tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id
WHERE tt1.taxonomy = 'category'
AND posts.post_status = 'publish'
AND tt1.term_id IN (".implode(",",$instance['category_id']).") AND
tt2.taxonomy = 'post_tag'
Wenn man dann eine Liste von Tags hat, kann man einfach das include Attribut beim Aufruf der wp_tag_cloud Funktion verwenden, um die neue Schlagwortwolke anzuzeigen.
Mikroformate definieren Klassen die bei beliebige HTML-Tags verwendet werden, um Maschinen semantische Informationen mitzuteilen. Unter der verschiedenen Möglichkeiten dieses Ziel zu erreichen, haben Mikroformate den Vorteil, dass sie keine Änderung der HTML-Spezifikation darstellen, sondern nur existierende Artefakten verwenden und weiter spezifizieren.
Es gibt verschiedene Mikroformate, um viele verschiedene Arten von semantischen Informationen zu kodieren:
Adressen
geographische Koordinaten
Atom-Informationen
Dienste bzw. Produkt-Listen
Media-Informationen
Nachrichten
Rezepte
Lebensläufe
Reviews von Dienste bzw. Produkte
Und noch mehr…
Ein verbreiteter Beispiel davon ist der hCard-Mikroformat. Mit einem schönen CSS-Stylesheet könnte folgendes gut aussehen:
Henri Benoit
amazingweb GmbH
hb@amazingweb.de
Ölmühlweg 37
Königstein, Hessen, 61462
Deutschland
+49 6174 297365
Es ist zwar für Menschen verständlich aber für Maschinen schwierig zu interpretieren. Mit dem hCard-Mikroformat würde man diese Kontaktdaten so kodieren:
Mikroformate werden auch von Google verwendet, um Suchergebnisse sinnvoller darzustellen. Wenn man z.B. nach einem Produkt sucht und es such Ergebnisse aus Webseiten gibt, wo Kunden auch Reviews abgeben können, und diese Daten mit Mikroformate kodiert werden, kann Google gleich die Note die vergeben wurde mit anzeigen und auch sagen, dass X Personen eine Note abgegeben haben. Es sieht dann in den Suchergebnisse so aus:
In diesem Beispiel sieht der HTML-Code so aus:
amazingweb GmbHamazingweb GmbHhttp://www.amazingweb.de
Bewertung :
98 von 100
bei
457 Bewertungen.
Einfach die beste Internetagentur !
Wie ein Mikroformat später bei Google aussehen wird, kann auf dieser Seite sehen. Da kann man entweder eine URL eingeben, wenn die Seite schon auf Internet sichtbar ist oder einfach HTML-Code eingeben.
Um Mikroformate zu verwenden muss man folgendes tun:
Beim Tag der die ganze Daten enthält, muss man eine spezielle Klasse verwenden, die dann sagt, was für ein Mikroformat verwendet wird, z.B.:
oder:
hreview-aggregate ist der Mikroformat für konsolidierte Review-Ergebnisse. vcard der Mikroformat für Kontaktdaten.
Man sieht oben, dass es keine Rolle spiel was für ein HTML-Tag verwendet wird. Natürlich macht es eigentlich nur Sinn Tags zu verwendet die Containers sind (wie div oder span).
Zusätzlich werden alle interpretierbaren Daten einzeln mit einer definierten Klasse markiert z.B. bei hreview-aggregate:
item für den Produkt selbst. item wird als Container verwendet und kann folgendes noch enthalten:
fn für den Name des Produktes
url für die Webadresse
rating für die Bewertung. rating wird als Container verwendet und kann folgendes noch enthalten:
average für die durchschnittliche Bewertung
best für die bestmögliche Bewertung
worst für die niedrigste Bewertung
votes für die Anzahl von abgegebenen Noten
count für die Anzahl von Reviews
photo kann auch verwendet werden, um ein Bild des Produktes zu zeigen
summary für die Zusammenfassung der Reviews
Man sollte auch beachten, dass wenn man count statt votes verwenden, sollte man theoretisch auch danach alle Reviews auflisten. Es führt aber anscheinend bei Google nicht zu Probleme.
Man kann nicht alle Daten die mit Mikroformat markiert werden in den Suchergebnisse sehen aber es macht trotzdem Sinn sie zu machen, weil sie dann bei anderen Anwendungen sichtbar sind.
In den früheren Tagen der Webentwicklung diente HTML dazu Inhalt, Struktur und Aussehen einer Webseite zu definieren.
Mit der Einführung von CSS, gab es eine Wanderung zu einer Art Modell-Präsentation-Muster, wo CSS für die Präsentation zuständig war und HTML nur noch für Inhalt und Struktur.
Mit JavaScript (und besonders mit den vielen JavaScript-Bibliotheken die es zur Zeit gibt) kam man langsam zu einem Modell-Präsentation-Kontroller-Muster (Model-View-Controller), wo JavaScript die Kontroller-Seite übernommen hat.
Aber die Vermischung von Inhalt und Struktur war immer noch da. Das Problem dabei ist nicht nur, dass Inhalt und Struktur beide in HTML definiert wurden, sondern, dass es gar keine richtige Möglichkeit gab, sie zu trennen bzw. zu unterscheiden.
Die strukturelle Seite von HTML wurde vor HTML5 meistens zu einem Baum von div Tags reduziert. Das ist nichts anders als eine Gruppierung von Teilen der Webseite, die aber meistens dadurch entstanden ist, dass man diese Teile in CSS bzw. JavaScript getrennt ansprechen möchte. Es war also mehr eine Präsentation- bzw. Kontroller-getriebene Strukturierung des Inhalts aber auf keinem Fall eine semantisch-relevante Strukturierung.
Eine von den wichtigen Neuerungen in HTML5 adressiert genau dieses Problem. HTML wird jetzt semantisch. Konkret heißt es, dass man in HTML5 die verschiedene logische Teile einer Webseite jetzt auch mit dedizierten HTML-Tags definieren kann. Die Meisten Webseiten haben so eine Struktur (oder eine relativ ähnliche Struktur):
Es gab also schon vor HTML5 eine semantische Strukturierung der Webseiten. Es war aber keine standardisierte Strukturierung, sondern jeder konnte es wie er wollte definieren.
Die Einzigen wirklich semantische Tags, die es in HTML4 gab, waren die Header Tags (h1 bis h6). Sie wurden leider oft nur als Formatierungstags verstanden, auch wenn sie wieder durch ihre Interpretation durch Suchmaschinen langsam wieder mehr semantisch wurden.
In HTML5 wurden spezielle Tags definiert, die es ermöglichen, um diese ganze div Containers zu ersetzen und um die Struktur von jeder Webseite standardisiert zu kodieren. In HTML5 wurde es so aussehen:
Der nav Tag kann entweder innerhalb vom header Tag oder außerhalb positioniert werden. Es kommt darauf an, wie man den Header genau versteht.
Der section Tag ist relativ ähnlich zum div Tag. Der Unterschied liegt daran, dass der section Tag auch bedeutet, dass die Inhalte die zusammengefasst werden auch thematisch zusammenhängen, was beim div nicht zwingend der Fall war.
In einem article bzw. section Tag kann natürlich auch einen header Tag verwendet werden, um den Artikel-Titel bzw. Widget-Name zu definieren. Es ist auch interessant zu sehen, dass moderne Browser dadurch auch h1 bis h6 unterschiedlich darstellen abhängig davon, auf welcher Ebene sie sind. Folgendes:
So haben diese Header Tags wieder eine reine semantische Bedeutung und sind nicht mehr reine Formatierungselemente.
Diese neue HTML5-Struktur ist schöner und, semantisch gesehen, sinnvoller. Sie hat aber einen Nachteil: Ältere Browser verstehen sie nicht. Deswegen werden oft beide Strukturen kombiniert. Die ältere Browser ignorieren einfach die neue Tags, die sie nicht kennen und sehen dann nur die alte Struktur. Neuere Browser sehen aber beide Strukturen, was unschön ist (aber wenn man ältere Browser unterstützen muss, ist man sowieso auf Kompromisse angewiesen). So eine kombinierte Struktur sieht dann so aus:
Natürlich mit der Struktur ist die Frage berechtigt, ob es überhaupt Sinn macht, die HTML5 semantische Tags zu verwenden. Da gibt es 2 Fälle:
Ist man nicht auf der Unterstützung von älteren Browser hingewiesen, kann man einfach nur die alte DIV Tags durch die neue semantische Tags ersetzen.
Ist es nicht der Fall, ist es zwar mehr Arbeit und die lesbarkeit leidet darunter, aber funktional gesehen, verliert man nichts und diese neue HTML5-Tags werden immer eine größere Rolle bei Suchmaschinen spielen. So kann es dafür gesorgt werden, dass Besucher meistens wegen des Inhalts zu der Seite gelangen und nicht weil es was in der Seitenleiste gibt. Die Absprungsrate wird dadurch niedriger.
Der Umstieg lohnt sich langfristig auf jeden Fall und ist auch von der technischen Seite nicht so aufwändig.
Das HTML5-Tag <time> adressiert den Bedarf für das semantische Kennzeichnen eines Datums bzw. einer Uhrzeit. Es ermöglicht die Definition sowohl eines von Maschinen als auch von Menschen lesbaren Datum bzw. einer Uhrzeit. Auf diese Weise können Sie einfach „Gestern“ dem Benutzer angezeigen und Software die ihre Seite parsen wissen lassen, dass es tatsächlich der 7. Dezember 2012 war.
<time> ist natürlich auch nützlich wenn man mit unterschiedlichen Zeitzonen arbeitet. Angenommen, Sie leben in Deutschland, sind aber auf einer Geschäftsreise in Indien und schreiben ein Artikel um 14 Uhr. Für den Leser ist es offensichtlich, dass es 14.00 Uhr indische Zeit ist. Aber eine Maschine wird nicht verstehen, dass, wenn Sie 14 Uhr schreiben, es normalerweise 14 Uhr mitteleuropäischer Zeit bedeutet, aber in diesem bestimmten Artikel ist es nicht der Fall. Auf der anderen Seite, lesen Besucher ihrer Seite sicher nicht gern Uhrzeiten Angaben mit Zeitzonen-Offset (besonders, wenn es aus dem Kontext klar ist, um welche Zeitzone es sich handelt).
Das <time> tag zu verwenden ist ganz einfach. Hier ein Beispiel:
<time>2011.12.25</time>
Natürlich, hier nur „2011.12.25“ als Datum / Uhrzeit zu markieren, bring nicht unbedingt viel. Wenn das datetime-Attribut nicht verwendet wird, muss der Inhalt der Zeitmarke ein gültiges Datum / Uhrzeit enthalten d.h. ein maschinenlesbare Datum / Zeit sein.
Es wird erst wirklich interessant, wenn man „Vergangenes Weihnachten“ als Menschen lesbares Datum schreibt und Robote mitteilt, dass es als den 25. Dezember 2011 zu verstehen ist. Das ist auch wirklich einfach. Man muss einfach folgendes verwenden:
Wenn ein Datum und eine Uhrzeit angeben werden, muss entweder einen Offset gegenüber der UTC-Zeit oder „Z“ für die UTC-Zeit angegeben werden z.B. 2012-12-13T23:07+00:00 ist dasselbe wie 2012-12-13T23:07Z.
Ein Teil des Datums kann auch weggelassen werden z.B. 12-08 für den 8. Dezember oder es kann auch ein Dauer angegeben werden. Ein Dauer-Angabe fängt mit einem P an (wie Period) und wird so definiert:
PnYnMnDTnHnMnS z.B. P3Y für drei Jahre oder PT2H25M für 2 Stunden und 25 Minuten
PnW z.B. P2W für 2 Wochen
Beachten Sie, dass P1M einen Monat bedeutet und PT1M eine Minute.
Eine Einschränkung vom <time> Tag ist, dass es nur Daten in der christlichen Ära darstellen kann. Ältere Daten können nicht kodiert werden. Also, wenn Sie eine Online-Biographie von Julius Caesar erstellen, werden Sie das <time> Tag kaum verwendet können (außer bei Verweisen auf Bücher die über ihn später geschrieben wurden).
Beachten Sie, dass das <time> Tag aus der HTML5-Spezifikation im letzten Jahr wurde entfernt (um vom <data> tag ersetzt zu werden), aber es wieder in HTML5 kurz danach wieder aufgenommen wurde. So ist die Zukunft von diesem Tag nicht 100% klar, aber zumindest ist es in WordPress und Drupal übernommen worden. So ist es recht verbreitet.
Der pubdate Attribut wird verwendet, um zu sagen, wer das angegebene Datum/Uhrzeit, der Zeitpunkt darstellt, wann der Artikel / das Dokument veröffentlicht wurde. Um genau zu sein, sagt es, dass es sich um die Veröffentlichung des nähersten <article> falls vorhanden oder des gesamten Dokument. Es gibt auch Chancen, dass pubdate aus der HTML5-Spezifikation entfernt wird. Deshalb melden mehrere HTML5-Validatoren seine Präsenz als Validierungsfehler.