HTML5 – ein Überblick

Clemens Kaposi arbeitet als Software Engineer im Mobilfunkbereich und ist in seiner...

 Sponsorenliebe

Endlich smarte Buchhaltung!

We Billing

HTML5 ist derzeit in aller Munde.  Ende Mai ließ Google auf der Entwicklerkonferenz »Google I/O 2009« in San Francisco aufhorchen, als groß Werbung für den zukünftigen Webstandard betrieben wurde, welcher die Basis für kommende Google-Anwendungen stellen soll.  Einen weiteren Schub erhielt die neue HTML-Version, als das Standardisierungskonsortium W3C (englisch) Anfang Juli die Einstellung der Arbeiten am parallel entwickelten XHTML2-Standard ankündigte, um sich voll und ganz auf HTML5 konzentrieren zu können.

HTML5 soll das in die Jahre gekommene HTML4 beziehungsweise XHTML 1 ablösen und besser an die neuen Anforderungen des vielzitierten Web 2.0 angepasst sein. Aufwändige Workarounds sollen damit der Vergangenheit angehören.  Die Entwicklung wird von der WHATWG (englisch) (Web Hypertext Application Technology Working Group) vorangetrieben, einer Arbeitsgruppe, die aus dem W3C heraus entstanden ist.  Mit Ausnahme Microsofts sind alle namhaften Browserhersteller in der WHATWG involviert.

Wer sich bereits der neuen Technologie annehmen will, muss nicht notwendigerweise alles Alte über Bord werfen.  HTML5 versucht großteils, abwärtskompatibel zu sein.  Wer aktuell mit den Strict-Varianten von HTML4 oder XHTML 1 arbeitet, muss grundsätzlich nur die Doctype-Deklaration auf <!DOCTYPE html> ändern und einige wenige Elemente entrümpeln, die nur der visuellen Darstellung dienen, oder für die es bessere Alternativen gibt.  Natürlich kann man erst mit den neuen Elementen und Attributen die Stärken von HTML5 richtig nutzen.

Struktur ist Alles

HTML5 kennt einige neue Elemente zur besseren semantischen Strukturierung von Dokumenten.  Diese sind vor allem dazu da, um mit den inzwischen verbreiteten <div id="…">-Blöcken aufzuräumen und den Aufbau einer Seite standardisiert auszuzeichnen.  Die Schlüsselrollen nehmen hierbei die neuen Elemente header, nav, article, aside und footer ein, welche – grob umrissen – folgende Aufgaben erfüllen:

  • header umfasst den Kopfbereich eines Dokuments und kann typischerweise den Titel des Dokuments, Logos, ein Formular zur Schnellsuche oder ein Inhaltsverzeichnis enthalten.
  • nav ist – nomen est omen – für Hauptnavigationsblöcke gedacht.
  • article ist der Ort für die eigentlichen Inhalte der Seite.  Die Verwendung soll so erfolgen, dass article-Blöcke, für sich genommen, alleinstehend sind, also beispielsweise auch unverändert als Inhalt eines Newsfeeds verwendet werden könnten.  article-Blöcke können mit section in mehrere Abschnitte unterteilt werden und sind außerdem schachtelbar.
  • aside beheimatet Abschnitte, die nicht unmittelbar mit dem eigentlichen Inhalt zusammenhängen – ein klassischer Fall für Sidebars, aber auch für inhaltliche Einschübe in einem article.
  • footer beinhaltet das, was man üblicherweise im Fußbereich eines Dokuments findet: Autor- und Copyright-Informationen oder Querverweise.  footer kann, aber muss nicht notwendigerweise am Ende eines Dokuments stehen.

Das aktuelle Grundgerüst der Seiten des Dr. Web Magazins liefert ein prädestiniertes Beispiel für gängige HTML-Strukturen, und ließe sich einfach mit den neuen HTML5-Strukturelementen formulieren.

Reformulierung des HTML-Grundgerüsts des Dr. Web Magazins in HTML5

Reformulierung des HTML-Grundgerüsts des Dr. Web Magazins in HTML5

Mehr Wert durch mehr Bedeutung

Ausgesprochen nützlich sind jene Elemente, die nicht nur ein Mehr an Struktur bringen, sondern auch die Semantik auf Textebene bereichern.

Mit dem time-Element kann man Datums- und/oder Zeitangaben im Text gesondert auszeichnen.  Angaben à la »übermorgen« kann man mit Hilfe des datetime-Attributs präzisieren.  Das genaue Datum (beziehungsweise Uhrzeit) muss dabei im ISO-Format angegeben werden:

Der diesjährige »CSS Naked Day« <time datetime="2009-04-09">anfang April</time> fand wieder mehr als 1000 Unterstützer aus aller Welt.

Durch die maschinenlesbaren Metaangaben ist beispielsweise eine Funktion zum Exportieren in ein Kalenderprogramm denkbar.  Das time-Element eignet sich leider nicht für historische Angaben (die oft ungenau sind, etwa »19. Jahrhundert«) oder Daten, die nicht den gregorianischen Kalender verwenden.  Dieser Umstand wird allerdings noch diskutiert, und es scheint, als sei hier das letzte Wort noch nicht gesprochen.

Ein weiteres nützliches Element ist mark.  Mit mark können Textpassagen hervorgehoben werden, wie man es mit einem Leuchtstift auf Papier machen würde.  Ein klassischer Verwendungszweck ist das Hervorheben von Schlüsselbegriffen auf einer Seite, die als Ergebnis einer Suche geliefert wurde.

<p>In der Bucht von San Francisco befindet sich unter anderem die ehemalige Gefängnisinsel <mark>Alcatraz</mark>, wo eine Flucht nahezu unmöglich war.</p>

Anzeigebeispiel für mit dem neuen mark-Element hervorgehobenen Text

Anzeigebeispiel für mit dem neuen mark-Element hervorgehobenen Text (Opera 10.01/Linux)

Entwickler von Web-Applikationen werden das neue Element progress begrüßen.  Es erlaubt, den Fortschritt einer Aufgabe anzuzeigen – beispielsweise als Prozent- oder Sekundenangabe – und via JavaScript laufend zu aktualisieren. Mit dem Attribut value (beziehungsweise mit dem Elementinhalt) läßt sich der aktuelle Wert setzen.  Das max-Attribut spezifiziert den Wert, der bei Vervollständigung des Tasks erreicht wird.  Ein enger Verwandter von progress ist meter, welches einen statischen Überblick über einen aktuellen Ist-Zustand gibt, etwa den aktuellen Platzverbrauch des eigenen Webmail-Kontos:

Fortschritt: <progress max="100" value="67">67%</progress>
<meter min="0" max="100" value="75">75 von 100 MiB verbraucht</meter>

Multimedia total

Eine weitere Neuerung stellt das Element figure dar.  Damit können Abbildungen mit einer Beschriftung versehen werden (legend), wie man es aus dem Printbereich kennt.  Bislang mußte man sich dazu mit Mikroformaten (englisch) behelfen.  Man ist dabei freilich nicht auf Fotos oder Grafiken beschränkt, sondern kann dies beispielsweise auch für Videos oder Programmier-Codeausschnitte verwenden, zum Beispiel:

<figure>
<img src="golden-gate-bridge.jpg" alt="" />
<legend>Abbildung 1.  Die Golden Gate Bridge. (© Christian Mehlführer)</legend>
</figure>
<figure>
<pre><code>print "Hello, world!"</code></pre>
<legend>Abbildung 2.  Das »Hello, world!«-Programm in Python.</legend>
</figure>

Anzeigebeispiel für ein mit dem figure-Element eingebettetes Bild (Opera 10.01/Linux)

Anzeigebeispiel für ein mit dem figure-Element eingebettetes Bild (Opera 10.01/Linux)

Vor allem Bilder- und Videogalerien werden von diesem neuen Element profitieren und zukünftig einheitlich ausgezeichnet werden können, womit man auch schon bei der nächsten Neuerung angelangt ist: den Elementen video und audio.

Zunehmende Bandbreiten haben in den letzten Jahren die sprunghafte Verbreitung von Videodaten im WWW möglich gemacht, Stichwort: YouTube.  Mittlerweile findet man Filmchen und Audioschnipsel an allen Ecken.  Dieser Trend war bei der Erstellung der alten HTML-Spezifikation vor zirka zehn Jahren, als die heutigen Möglichkeiten des Internet noch nicht einmal in den Kinderschuhen steckten, nicht absehbar.  Entsprechend umständlich ist bisweilen immer noch die browser- und plattformübergreifende Einbindung von Multimediadateien.

video und audio sollen dem ein Ende setzen und bieten eine einfache Lösung an:

<video src="montana-to-rice.ogv" type="video/ogg; codecs='theora, vorbis'" controls="controls"></video>
<audio src="the-play-radio-call.oga" type="audio/ogg; codecs='vorbis'"></audio>

Anzeigebeispiel für ein mit dem video-Element eingebettetes Video (Firefox 3.5.4/Linux)

Anzeigebeispiel für ein mit dem video-Element eingebettetes Video (Firefox 3.5.4/Linux)

Wenn – wie im Beispiel – das controls-Attribut gesetzt ist, können die Browser dann selbst alle nötigen Kontroll-Elemente zur Steuerung anzeigen, etwa Fortschrittsbalken, Start/Pause-Schaltfläche oder Lautstärkenregelung.  Die Crux an der Geschichte, es wird in der Spezifikation wohl kein gemeinsames Audio- und Videoformat festgelegt werden, welches jeder Browser unterstützen sollte.  Daher ist es ratsam, mit dem type-Attribut den MIME-Type der eingebundenen Mediendatei zu spezifizieren. Ursprünglich waren die freien Codecs der Ogg-Familie (englisch) als gemeinsame Basis angedacht, doch das widerspricht beispielsweise Apples Interessen, welches sein hauseigenes Quicktime-Format vorantreiben will.  Somit müssen Videoersteller weiterhin hoffen, daß eine möglichst große Zahl an Clients ihr gewähltes Videoformat unterstützt.  Ob damit eine Abkehr von den gängigen suboptimalen Flash-Lösungen gelingt, bleibt abzuwarten.

Web-Applikationen

Die größte Aufmerksamkeit erregt aktuell das canvas-Element.  Es stellt grundsätzlich eine 2D-Bitmap-Zeichenfläche frei definierbarer Größe zur Verfügung.  Mittels JavaScript kann man darin zeichnen und Grafiken on-the-fly erstellen.  Somit lassen sich zum Beispiel Diagramme einfach dynamisch generieren, oder man kann auch Mini-Spiele damit produzieren.

<canvas width="150" height="100" id="canvas" />

wird mit entsprechendem JavaScript

var canvas = document.getElementById('canvas');
if (canvas.getContext) {
var ctx = canvas.getContext('2d');
ctx.fillStyle = 'rgba(160, 63, 63, 0.5)';
ctx.fillRect(20, 20, 80, 60);
ctx.fillStyle = 'rgba(63, 63, 160, 0.5)';
ctx.fillRect(70, 30, 40, 60);
}

zu

Anzeigebeispiel für eine canvas-Zeichnung (Firefox 3.5.4/Linux)

Anzeigebeispiel für eine canvas-Zeichnung (Firefox 3.5.4/Linux)

An und für sich wären solche Anwendungen auch mit dem bereits etablierten XML-Vektorformat SVG (englisch) realisierbar, doch der Durchbruch im Web wurde bei SVG nie erreicht.  Auch wenn sich der Browserhersteller aus Redmond mit der Unterstützung von canvas noch ziert, besteht hier mehr Hoffnung.  Das neue Element ist zum einen ein Teil der kommenden Spezifikation und keine eigenständige Technologie und zum anderen bringt es eine flachere Lernkurve mit sich, da es über das Entwicklern bereits vertraute JavaScript zu bedienen ist.

Web Forms 2.0

Wo Web-Applikationen sind, sind Formulare nicht weit.  HTML4 stellt nur allgemeine Formularelemente zur Verfügung, wie zum Beispiel Texteingabe- und Passwortfelder, Checkboxen oder Dropdown-Listen.  Wenn man in einem Textfeld etwa eine Datumseingabe erwartet, so ist man in der Regel gezwungen, serverseitig zu verifizieren, ob es sich bei der Benutzereingabe überhaupt um ein gültiges Datum handelt.  Ähnlich verhält es sich bei URLs, numerischen Werten oder anderen Eingaben.

HTML5 erweitert die Möglichkeiten des input-Elements beträchtlich, indem es dem type-Attribut einige neue Werte beschert.  So kann man beispielsweise mit type="email" angeben, dass man eine E-Mail-Adresse erwartet.  Die Überprüfung, ob es sich bei einer Eingabe um eine gültige Adresse handeln kann, findet dann bereits direkt im Browser statt – ohne, dass der Web-Entwickler dazu einen Finger rühren muss.  Weitere neue type-Werte sind date, time und datetime (bzw. datetime-local) für Datums- und/oder Zeitangaben, number für numerische Werte, color für RGB-Farbwerte in Hex-Notation oder url für Internetadressen.

Anzeigebeispiel für einige der neuen input-Eingabetypen (Opera 10.01/Linux)

Anzeigebeispiel für einige der neuen input-Eingabetypen (Opera 10.01/Linux)

Für komplexere Fälle kann man über das pattern-Attribut ein Suchmuster in Form eines regulären Ausdrucks angeben, auf welches der Eingabewert zutreffen muss.  Sehr praktisch ist in dieser Hinsicht auch das neue Attribut required.  Wenn es gesetzt ist, muss das betreffende Feld vom Benutzer ausgefüllt werden, unabhängig von möglichen weiteren Werteinschränkungen.

Ein weiteres Highlight des neuen input-Elements ist das autocomplete-Attribut.  Setzt man dieses auf on, so wird dem Browser signalisiert, dass Eingaben in dieses Feld gespeichert und bei zukünftigen Seitenaufrufen zur automatischen Vervollständigung angeboten werden sollen – ein klassischer Anwendungsfall für Suchfelder.  In dieselbe Kerbe schlägt das list-Attribut, wo man die id eines im Dokument angeführten datalist-Elements angeben kann. Die option-Einträge unterhalb der so verknüpften datalist dienen dem input-Element als Eingabevorschläge.

<label for="datalist">Suche Statistiken für…</label>
<input id="datalist" type="text" name="name" list="mylist" />
<datalist id="mylist">
<option value="Joe Montana" />
<option value="Jerry Rice" />
<option value="Steve Young" />
</datalist>

Anzeigebeispiel für ein input-Feld mit Eingabevorschlägen eines datalist-Elements (Opera 10.01/Linux)

Anzeigebeispiel für ein input-Feld mit Eingabevorschlägen eines datalist-Elements (Opera 10.01/Linux)

Nützlich ist ebenfalls das Attribut autofocus.  Ist es bei einem Element gesetzt, so wird dieses automatisch fokussiert, sobald die Seite vollständig geladen ist.  Damit kann ein Benutzer sofort mit dem Ausfüllen eines Formulars beginnen, ohne erst noch das betreffende Eingabefeld extra anklicken zu müssen.

Allein durch diese hier aufgezählten Neuerungen werden zahlreiche gängige JavaScript-Lösungen durch einen einheitlichen Standard obsolet.

Schöne neue Welt

Der Standardisierungs- und Spezifizierungsprozess von HTML5 ist aktuell noch im Gang und soll bis 2010 abgeschlossen werden.  Dieser Artikel stellt nur einen kurzen Streifzug mit einer unvollständigen Auswahl an neuen Elementen dar.  HTML5 kann darüber hinaus auch noch viel mehr – beispielsweise werden JavaScript-Schnittstellen zur Benutzerinteraktion definiert, unter anderem Drag-and-Drop-Support.

Der Haken am neuen Webstandard: die Browser-Unterstützung steckt noch in den Kinderschuhen.  Einzig in puncto Formulare sticht Opera mit Implementierung der meisten neuen Funktionen hervor und auch WebKit-Browser wie Apples Safari sowie Google Chrome können in diesem Bereich schon einiges vorweisen.  video, audio und canvas können zum Teil schon bei Firefox sowie Safari und Chrome verwendet werden. Darüber hinaus gibt es immer wieder nur punktuellen Support für einzelne Features. Die englischsprachige Wikipedia bietet laufend aktualisierte Vergleichstabellen an.

Dies muss jedoch nicht notwendigerweise ein Hindernis für den Einsatz sein.  Dank Graceful degradation werden unbekannte Elemente meist sinnvoll dargestellt.  Stolpert ein Browser beispielsweise in einem Dokument über das ihm unbekannte mark-Element, so wird der Inhalt üblicherweise als normaler Fließtext dargestellt.

Bis auf Microsofts Internet Explorer lassen sich die neuen Elemente grundsätzlich tadellos via CSS formatieren und auch dem Redmonder kann man mit dem HTML5 enabling script (englisch) von Remy Sharp auf die Sprünge helfen. Alternativ kann man dem IE auch mit einem Plugin, Google Chrome Frame (englisch), moderne HTML5-Funktionalität beibringen.

Konkrete Beispiele, wie HTML5 bereits heute schon in freier Wildbahn eingesetzt wird, bietet die HTML5 Gallery (englisch), wo ambitionierte Entwickler von bestehenden Seiten lernen und sich inspirieren lassen können.

Mit HTML5 besteht die große Chance auf eine einheitlichere Browserunterstützung eines Standards. Die teilweise wüsten Auswüchse von browsereigenen Features aus dem ehemaligen Browserkrieg zwischen Netscape und Internet Explorer können ebenso wie diverse Altlasten endgültig entsorgt werden. ™

Clemens Kaposi

Clemens Kaposi arbeitet als Software Engineer im Mobilfunkbereich und ist in seiner Freizeit als Entwickler von Web-Applikationen tätig. Er ist Herausgeber von 49ersFanZone.net, der deutschsprachigen Community für Fans der San Francisco 49ers. Clemens studierte Angewandte Informatik an der Universität Salzburg.

43 Kommentare

  1. Sehr schön.

    Bis auf den unschönen Fehler das figure nicht mit legend benutzt werden kann, das ist invalider HTML Code.
    Zum Beschriften von figure wird figcaption benutzt.

    Ich weiss jetzt allerdings nicht wie das zu dem Zeitpunkt war als der Artikel erstellt wurde.

  2. Verrückt wenn man sich mal überlegt was wir in den letzten zehn Jahren für eine Entwicklung mitgemacht haben. HTML5 ist mal wieder das nächste Level und bis es wirklich in allen Lebenslagen und Interaktionen verwirklicht ist, gibt es schon wieder das nächste Level!
    Unsere Grosseltern dachten, sie hätten bei der Erfindung des Telefons was großes miterlebt… hardcore! I love it!

  3. Die Möglichkeit, Text mehrspaltig darzustellen, wird es in Zukunft wohl geben. Da es sich dabei allerdings um etwas handelt, das lediglich der optischen Darstellung dient, ist das ganze nicht in HTML5 sondern in CSS3 angesiedelt – Stichwort »Multi-column Layout Module«. Die Einführung zur aktuellen W3C-Empfehlung liefert ein paar schöne Beispiele hierzu: http://www.w3.org/TR/css3-multicol/

  4. Pingback: twive!
  5. Sehr guter Beitrag!

    Eine Frage an den Autor: Ich habe gehört, dass es in HTML 5 möglich sein soll Text mehrspaltig zu layouten, ohne dafür div id=”links”, id=”mitte”, usw… zu benutzen. Also so etwas wie “spalten” mit attributen für anzahl, höhe etc. Gibt es dieses Element wirklich, oder ist das nur ein Gerücht?

  6. Vielen Dank für diesen gelungenen Artikel. Ich hab ihn mit grossem Interesse fast komplett durchgelesen (normalerweise überfliege ich sonst die meisten Artikel im Schnell-Lese-Verfahren). Freue mich schon jetzt auf HTML5, denn es bietet im Gegensatz zu früheren Erweiterungen des HTML-Standards allesamt nützliche Funktionen.

  7. @Harry Schmieder (#18): Ich kann mir schon denken, warum Google die logische Struktur verbessert haben will: Sie wollen so einfach wie möglich Artikel aggregieren. Da hilft “article” sehr dabei. Beispielsweise.

    Ich habe keine der Funktionen gesehen, die für den User interessant wären. Auch bei Video hat man sich nun nicht auf einen Standard geeinigt. Dem User ist es egal, wie logisch strukturiert eine HTML-Seite ist. Er schaut sie nur an. Er will ja den Content nicht maschinell weiterverarbeiten.

    Auf Seiten mit WErbung, die auch von Werbung leben, dürfte es etwas heikel werden. Was machen die, wenn sich die User per User-CSS nur “article” und “nav” zeigen lassen?

    Also entweder wird das dann nicht korrekt ausgezeichnet -um eben die Werbung anzuzeigen, Werbebanner also innerhalb “article” – oder es wird einfach auf werbefinanzierten Seiten nicht einsetzbar sein.

  8. Danke für die Info!

    für mich heißt dies aber, viel Mühe für etwas, dass man eigentlich nicht braucht. Eine vernünftige Auszeichnung hat man bei den heutigen Standards nach XHTML auch. Den Kunden interessiert es in der Regel überhaupt nicht (noch nicht mal die heutigen Standards) und er möchte deshalb dafür auch nicht bezahlen! Das Ganze ist hauptsächlich etwas für Spezialisten und Fetischisten 😉 – leider.

    Was mir auf den ersten Blick auch nicht gefällt, ist dass starre Korsett. Mit DIV’s, ID’s und Klassen, bin ich einfach fexibler, entsprechend meiner individuellen Anforderung/Site. Wenn man hier die aktuellen Standards vernünftig verwendet hat man genug Möglichkeiten. Bei CSS3 sehe ich es ggf. etwas anders, da es ja hier im wesentlichen um Gestaltung geht, und hierbei wiederum um Vereinfachung. Was der Kunde braucht sind “Einfach gute Websites” und wenig kompliziertes und aufwendiges :-). Und da MS$ nicht mit zieht bzw. dabei ist, wird dass nächste Problem wieder sichtbar… Also für was den Aufwand? – Leider.

    Gruß Johannes

  9. Danke für diesen Überblick.
    Wasser auf unsere Mühlen.
    Aber bis das mal umgesetzt ist, wird noch viel Wasser die Isar hinab fliessen. Die (sehr große) Firma in der ich nebenbei arbeite, hat Anfang 2009 (!) den Standard-Browser ihrer Firmen-Rechner von IE6 auf IE7 umgestellt…

  10. Die Definition von «aside» wurde übrigens im ehemaligen Sinn geändert – «aside» steht nur für Elemente, die sekundäre Informationen relativ zum Artikel bzw. zur Seite bieten – es sollte also innerhalb eines article-elements nicht als direkten Ersatz von «sidebar»-Divs benutzt werden.
    siehe auch http://html5doctor.com/aside-revisited/

  11. Wirklich ein toller Bericht. Ich freue mich schon auf die neuen Standards. Auch wenn ich zugeben muss, mich selten 100% an Standards gehalten zu haben. Dem Großteil meiner Kunden sind diese Standards egal, denn sie erzielen keinen Gewinn. Selbst die Extrakosten die wir für den IE6 nehmen, werden ohne Murren bezahlt. Ich hoffe das dieser Browser irgendwann stirbt und das der Hersteller seine Programme zukünftig anders optimiert. Die Philosophie von Microsoft ist ja längst bekannt. Schade eigentlich. Wäre das nicht wunderbar, wenn wir eine Website/Projekt umsetzen, die auf allen Browsern gleich aussieht/läuft und die verschiedenen Browser nur noch dazu da wären, um unterschiedliche Funktionen anzubieten bzw. er unabhängig von der Renderengine wäre? *traumende* 🙂

  12. Gute und interessante Hinweise von Clemens Kaposi, dafür meinen Dank.

    Wenn allerdings die Standardisierung von HTML 5 für die wichtigsten Browser genauso lange dauert wie die von CSS 3, dann sehe ich schwarz für die effektive Nutzung von HTML 5 in naher Zukunft.

    Es ist wirklich längstens an der Zeit, den wichtigsten Browser-Herstellern gewisse Dinge “aufzuzwingen”, die sowohl für Seitenentwickler wie auch für Benutzer wichtig und gut sind.

    Eine zeitnahe Umsetzung aller Browser-Lieferanten zumindest der sinnvollsten Neuerungen von HTML 5 und CSS 3 wäre zu erhoffen und zu erwarten.

    Bisher waren die Browser auf dem Markt nämlich nur so gut, wie es auch die Webdesigner waren! Weil – gerade seit Web 2.0 – NUR die Webdesigner großen Wert auf die Einhaltung aktueller Standards gelegt haben, wogegen es die meisten Browserhersteller mehr oder weniger nicht interessiert hat.
    Es sollte aber so sein: Ein guter Browser ist nur der, der die sinnvollen und vom W3C abgesegneten neuen Standards schnell und sauber implementiert!

    Und trotz zunehmender Anzahl von Seiten, die mit Hilfe von css in Form und Inhalt getrennt und an Annäherung an Barrierefreiheit erstellt sind, gibt es noch immer unzählige ärgerliche Darstellungs-Unterschiede und Interpretationsarten unter den Browsern.
    Da machen dann Browser wie wir sie kennen und auch das W3C nicht wirklich Sinn, und man sollte sich überlegen, ob zukünftig Browser nur noch von Webdesignern hergestellt werden.

    Das Internet gibt es jetzt schon über 16 Jahre. Langsam sollte man uns Webdesignern unsere Arbeit durch Einhaltung von Standards mal etwas leichter machen.

    Und auch gewisse Suchmaschinen sollten sich ihrer Wurzeln besinnen und darauf, dass sie schlichtweg dazu da sind, Seiten anhand von Suchbegriffen der User zu finden. Nicht aber, um Webdesignern vorzuschreiben, wie sie ihre Seiten erstellen müssen und viele andere Dinge berücksichtigen müssen, damit die Seiten überhaupt findbar werden.
    Das habe ich noch nie verstanden und das werde ich auch nie verstehen.

  13. Ich war schon immer ein Anhänger von HTML. Als Grundstruktur ist es
    im Browserbetrieb nicht mehr verzichtbar. Behandelt wurde es oft wie ein
    Gehbehinderter, der an Krücken gehen muß und in alle Richtungen wurde
    nach Alternativen gesucht. HTML zu verbessern und weiterhin zu benutzen,
    war die effektivere und klügere Idee. Schlank wirkt es und clever ist es auch,
    gute Handhabung wird versprochen. Ich bin begeistert, hat sich doch die
    Erkenntnis, simpel ist noch immer das Beste, gerade bei denen durchgesetzt,
    die gerne mal alles Alte über den Haufen werfen, auch um den Preis, daß
    Ihre Neuerungen alles verkomplizieren und einheitliche Standards
    grundsätzlich in Frage gestellt werden. Das muß vielleicht so sein, Hauptsache
    man findet anhand der Brotkrumen den Weg zurück. Na dann, viel neuen Spaß !

  14. Naja E-Mail und Datumseingabefelder hin oder her. Kontrollieren muss man trotzdem immer. Es ist immer einfacher zu schummeln und wenn man sieht wie viele User noch immer mit dem antiquierten IE6 unterwegs ist, da weiß jeder das es noch Jahre braucht ehe man wirklich mal eine HTML5-Seite effektiv erstellen und “verkaufen” kann.

  15. Hi Zusammen,

    ausser das DIVs nun sprechende Namen bekommen und es nun möglich ist clientseitig etwas “malen” zu lassen, ist das für mich kein Grund, warum es HTML5 geben soll. Besser wäre alle Browserhersteller würden sich auf EINEN Standart einigen und den auch kosenquent umsetzen. Alles Andere ist doch heute schon dank JS-Frameworks möglich. Einfach als JQuery und Co. geht es ja kaum noch, oder?

  16. @Fritz, das stimmt nicht ganz. In HTML 4 und damit auch in XHTML 1 ist dl eine »definition list«, also zum Auszeichnen von Definitionen gedacht.
    Wer in diesen Sprachen ein Bild mit den entsprechenden Elementen nur beschreibt aber nicht definiert, der erzeugt eben kein korrektes Markup, sondern nur eine Layouttabelle mit anderen Mitteln.

    Erst in HTML5 wurde das Element als »description list« umgedeutet, semantisch aufgeweicht und für eine breitere Anwendung aufbereitet. Das muß man nicht mögen – in HTML5 geht Pragmatismus eben vor Eleganz – aber wir können damit leben, denke ich.

    Ältere (nur?) Versionen JAWS’ behandeln das noch als Definitionsliste und sagen vor jedem dd »entspricht«.
    Darauf sollte man beim Auszeichnen und bei den Formulierungen noch eine Weile Rücksicht nehmen, denn ob des hohen Preises wird JAWS nicht oft aktualisiert.

  17. Hallo Clemens,

    »dt« und »dd« hat aber nichts mit HTML 5 zu tun, sondern wird auch unter den aktuellen (X)HTML Versionen genau für den beschriebenen Zweck schon seit langem verwendet, vor allem auf Seiten, die sich um semantisch korrektes Markup bemühen.

  18. Danke Thomas, Du hast natürlich völlig recht. Es tut mir leid, daß das an mir vorbeigegangen ist. Es werden nunmehr »dt« für die Beschriftung und »dd« als Wrapper für die Abbildung selbst »mißbraucht«. Eine typisch pragmatische Entscheidung.

  19. Super Artikel, der einen schönen Überblick gibt.
    Ich bin gespannt, wie schnell die Browserhersteller mit kompatiblen Versionen aufwarten.

    Spannend wird sicher auch, wie Google und andere Suchmaschinen den Einsatz von HTML5 in ihren Ranking-Algorithmen “belohnen”.
    Davon wird dann abhängen, wie schnell große kommerzielle Angebote entsprechend überarbeitet werden.

  20. Sehr interessanter Artikel.
    Ja bis das alle Browser unterstützen, ist die eine Seite.
    Bis alle User diesen Browser auch benutzen, ist die andere Seite. Wieviel surfen noch mit IE6?

  21. Schöne Übersicht, freu mich auf HTML 5 – kann es kaum abwarten. Bis das jedoch alle Browser unterstützen wird wohl noch einige Zeit vergehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.