Semantischer Code - Definitionen, Methoden, Zweifel

von Heike Edinger & Timo Wirth / 22. September 2005 /

Zweifel - Palast der RepublikEs gibt 1000 gute Gründe, semantischen HTML-Code zu schreiben. Das hat die Interview-Serie “Falling in love with CSS” gezeigt. Doch das Streben nach sauberem, bedeutungsvollem Code ist nicht immer einfach. Schnell wird der heldenhafte Entwickler von Zweifeln geplagt: Transportiert das verwendete Markup die größtmögliche Bedeutung? Doch das Zweifeln lohnt sich.

Dieser Text steht in Beziehung zu Retro-Coding: Sematischer Code ist der Anfang von gutem Design. Er ist aber keine Fortsetzung, sondern eher eine Ergänzung. Semantisch betrachtet, sind die Texte zwei <li>-Elemente in einer unsortierten Liste <ul>. Müsste man den ersten Text lesen, um diesen hier zu verstehen (was man nicht muss), könnte man auch eine nummerierte Liste <ol> verwenden. Doch der Reihe nach.

Ganz einfach ausgedrückt, bedeutet semantisches HTML nichts anderes als bedeutungsvolles HTML (Semantik = Lehre der Bedeutung). HTML-Code schreiben heißt somit nichts anderes als Inhalte gliedern, Strukturen schaffen, logische Beziehungen herstellen, Bedeutung markieren. Die HTML-Elemente übermitteln bei semantischem Code nicht wie die Inhalte aussehen sollen, sondern welche Bedeutung oder Funktion sie haben.

Gibt es in einem Online-Dokument eine Überschrift, ist es zunächst einmal nebensächlich, dass diese blau, fett und groß sein soll. Gibt es ein Zitat, ist es nebensächlich, dass dieses eingerückt werden soll. Gibt es eine Liste, ist es nebensächlich, dass kleine rote Quadrate vor jedem Aufzählungspunkt stehen. Das macht das Schreiben von HTML zu einer sehr fokussierten, fast einfachen Aufgabe.

Kein Gedanke muss an die Farbe, Größe oder Schrift verschwendet werden, kein Gedanke an die Abstände, Definitionen, Zitate sind so nicht optisch hervorgehoben, sondern logisch markiert und auch erkennbar für Menschen, die sich den Inhalt vorlesen lassen, oder Maschinen, denen das Aussehen egal ist (wie Google).

Der Ansatz ist nicht neu und im Grunde – wie in Retro-Coding beschrieben – “ein back to the roots”. Man verwendet HTML so, wie es von Anfang an gedacht war.

Semantic Markup is the result of using (X)HTML elements for their proper, intended usage. Dave Shea: Who Cares about Semantics Anyway?

Klingt einfach. Dennoch fällt es jedem, der in den 90er-Jahren HTML gelernt hat, schwer, nur an die Bedeutung zu denken. “Muss dieses Element nicht mehr Abstand nach unten haben?”, “Was ist mit den Umbrüchen? Hier gehören doch keine Umbrüche hin!” Nicht verzweifeln. Nicht ans Aussehen denken. Das ist die Aufgabe des Stylesheets. Die Gestaltung lässt sich umso besser mit CSS kontrollieren, je sauberer Struktur und Präsentation getrennt ist. Die zentrale Frage beim Schreiben von HTML-Code ist “Welche Bedeutung hat dieser Bereich?” und nicht “Wie soll dieses Element aussehen?” oder “Wo soll es platziert werden?”. Das Dokument wird universell verständlich.

Die Grundlagen: Eine Überschrift ist eine Überschrift ist eine Überschrift

Der erste Schritt hin zu semantischem Markup ist einfach: An den Inhalt (nicht das Aussehen) denken und dasjenige HTML-Element bevorzugen, dass den Inhalt am besten beschreibt. Die wichtigste Überschrift wird als Überschrift (heading) mit einem <h1>-Element gekennzeichnet, ein Textabschnitt als Absatz (paragraph) mit einem <p>-Element, eine Liste als unsortierte Liste (unordered list) mit einem <ul>-Element (Oh doch, das mit den dicken Bullet-Zeichen!). Es werden keine HTML-Elemente verschmäht, weil sie vermeintlich hässlich aussehen.

Beispiele für semantisches und nicht semantisches Markup

<!-- nicht semantisch :-( -->
<font size="4"><b>Eine Überschrift ist eine Überschrift?</b></font>
<div class="headline">Eine Überschrift ist eine Überschrift?</div>

<!-- semantisch :-) -->
<h1>Eine Überschrift ist eine Überschrift!</h1>

<!-- nicht semantisch :-( -->
<span class="p">Ein Absatz ist ein Absatz ist ein Absatz ist
ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz
ist ein Absatz ist ein Absatz ist ein Absatz?<br /><br />

Ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz ist ein
Absatz ist ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz
ist ein Absatz ist ein Absatz?</span>

<!-- semantisch :-) -->
<p>Ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz
ist ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz ist ein
Absatz ist ein Absatz ist ein Absatz!</p>
<p>Ein Absatz ist ein Absatz ist ein Absatz ist ein Absatz
ist ein Absatz ist ein Absatz ist ein Absatz ist ein
Absatz ist ein Absatz ist ein Absatz ist ein Absatz!</p>

<!-- nicht semantisch :-( -->

<a class="liste" href="#"> · Eine Liste></a><br />
<a class="liste" href="#"> · ist eine Liste</a><br />
<a class="liste" href="#"> · ist eine Liste?</a><br />

<!-- semantisch :-) -->
<ul>
<li><a href="#">Eine Liste</a></li>
<li><a href="#">ist eine Liste</a></li>

<li><a href="#">ist eine Liste!</a></li>
</ul>

Natürlich ist ein “ungeschmücktes”, rein auf seine Inhalte reduziertes HTML-Dokument kein berauschender Anblick. Doch alle Inhalte sind gut gegliedert, die Grundstruktur ist sichtbar (und unsichtbar!) markiert.

The way your page looks isn’t really relevant. The import part is that the information in the page is marked up in a way that describes what it is. Langridge. DHTML Utopia. Modern Web Design 2005:5

Klingt noch immer einfach? Okay, wir nähern uns langsam den Tücken. Denn nicht immer ist die Wahl des “richtigen”, des “bestmöglichen” HTML-Elements leicht. Des Öfteren stoßen wir schnell – wie es Molly Holzschlag treffend ausgedrückt hat – an die Grenzen der Spezifikation und die unserer Vorstellungskraft (Molly Holzschlag: The Meaning of Semantics, Take II).

Das Ziel: Semantischer Code

(X)HTML ist – anders als XML – keine vollends semantische Sprache. Es gibt eine begrenzte Anzahl an vorgegebenen, mit Bedeutung aufgeladenen Elementen. Nicht alles kann im Code bedeutsam markiert werden. Elemente für Datum, Autor, Kategorie, Zusammenfassung? Fehlanzeige.

Dem Entwickler sind folglich bei der Strukturierung von Inhalten Grenzen gesetzt. Doch dieser nicht alles erfassende, fast luftige Charakter der W3C-Spezifikation, bringt auch Vorteile: Das Vokabel-Lernen hält sich in Grenzen und der begrenzte Wortschatz bringt – richtig eingesetzt – Übersicht im Code.

Es ist also immer etwas idealistisch, von semantischem Code zu reden. Es gibt nun einmal nicht die einzig wahre Markup-Struktur. Es bleibt viel Raum für Auslegungen. Es bleibt viel Raum Diskussionen. Aber es bleibt auch die Möglichkeit, nach dem höchsten Maß an semantischem Gehalt zu streben – das Unmögliche anstreben, um das Best-Mögliche zu erreichen. Hier ein Definitionsversuch, wie man das Ideal am besten beschreiben könnte:

Semantischer Code
Semantischer Code ist die Verwendung von HTML-Elementen, welche in ihrem Kontext das Höchstmaß an Bedeutung kommunizieren.
Semantischer Code ist Code, der einen Bezug zum Inhalt herstellt. Er umschließt oder repräsentiert Inhalt und übermittelt dessen Bedeutung oder Funktion.
Semantischer Code ist nicht präsentationsgebunden, sondern informationsgetrieben. Er transportiert Sinngehalt nicht über die visuelle Gestalt, sondern über universell verständliche “Etiketten”. Er ist eine plattformunabhängige
Meta-Information.
Semantischer Code kommuniziert nicht nur Bedeutung, sondern verleiht auch Struktur. Es werden Beziehungen hergestellt und Hierarchien aufgebaut.
Semantischer Code existiert nur in Beziehung zu dem, was er bezeichnet. Ein leeres <p> transportiert keine Bedeutung, sondern erzeugt lediglich einen Effekt (es generiert Weißraum). Bedeutung entsteht dann, wenn zwischen einem öffnenden und einem schließenden Tag Text – also Inhalt – steht.

Semantischer Code hat seine Grenzen

Die bescheidene, schlichte Natur von HTML macht das Ziel, semantischen Code zu schreiben, zu einem sehr ehrgeizigen Ziel. Doch nicht verzweifeln. Es lohnt sich. Und man kann Techniken erlernen, um semantischem Code Stück für Stück näher zu kommen.

Die Methode: Fragen stellen und die Herausforderung annehmen

HTML-Elemente sollten verwendet werden, um Bedeutung zu markieren. Darum beginnt das Schreiben von semantischem Code immer mit den Fragen:

  • Was will ich eigentlich kommunizieren?
  • Welche Art von Informationen habe ich hier?
  • Wie kann ich meine Informationen am einfachsten und klarsten strukturieren?
  • Welche Bedeutung oder Funktion hat mein Inhalt?
  • Welche HTML-Elemente beschreiben die Inhalte am besten?

(Dran denken: Die Frage “Wie soll mein Inhalt aussehen?” stellt sich nicht.)

The emphasis as we write our HTML or XHTML has moved from how our content looks to what our content means. Molly Holzschlag: The Meaning of Semantics (Take I)

Die Herausforderung besteht darin, so wenig Code wie nötig zu verwenden und so viel Bedeutung wie möglich zu kommunizieren. Sich von solchen Werten leiten zu lassen, bringt nur immense Vorteile (dazu später mehr), sondern ist auch eine Frage der Ehre und des Handwerks:

Any web developer who cares about the quality of his craft should write the most logical and semantic code possible as this is a key factor of the craft. Andy Clarke: Falling in love with CSS

Nehmen wir die Herausforderung an – und stellen wir Fragen:

Betonung, Quellenangabe oder fremdsprachlicher Ausdruck?

Fast automatisch, ohne viel darüber nachzudenken, setzt jeder, der elektronisch einen Text schreibt, bestimmte Wörter oder Phrasen kursiv. Der Klick geht mechanisch auf den k-Button. Die Gründe dafür hat der Maschinenschreiber verinnerlicht. Doch kursiv ist nicht gleich kursiv. Was sind also die Motive? Welche Bedeutung steckt im markierten Textelement? Was soll kommuniziert werden?

Beispiel 1: Er war reichlich verspätet. Sie war jedoch froh, dasser kam.
Bedeutung: Ein wichtiges, betontes Wort. Ein Wort, das den Sinn des Satzes hebt.
Erklärung: Hier ist die Formatierung ein sprachliches Hervorhebungsmittel. Das Wort ist betont. Doch nicht nur physisch. Das i-Element (“italic”) scheidet somit aus. Denn was ist, wenn der Text vorgelesen wird? Um das Wort Endgerät-unabhängig abzuheben, ist <em> das beste Element. Es enthält nicht nur eine Information über das Aussehen (“kursiv machen”). Es drückt aus: Dieses Wort ist wichtig und soll betont werden. Am Bildschirm durch eine kursive Schrift, im Sprachbrowser durch Intonation.
Markup: Er war reichlich verspätet. Sie war jedoch froh, <em>dass</em> er kam.
Beispiel 2: Der New York Times Book Review schreibt …
Bedeutung: Eine Quellenangabe, ein zitiertes Werk oder ein zitierter Autor.
Erklärung: Hier übermittelt die Formatierung eine Meta-Information. Die kursive Schrift hebt – so die typographische Konvention – eine zitierte Quelle optisch ab. Das bedeutsamste HTML-Element wäre in diesem Fall <cite>.
Markup: Der <cite lang="en">New York Times Book Review</cite> schreibt ...
Beispiel 3: ein Redner par excellence
Bedeutung: Eine Passage / ein Wort in einer Fremdsprache.
Erklärung: Hier markiert die Formatierung einen Sprachwechsel. Um den fremdsprachlichen Ausdruck nicht nur optisch zu kennzeichnen, markiert man den Sprachwechsel über das lang-Attribut. Eine ausdrückliche Betonung ist nicht erwünscht, darum wäre es ungeschickt, ein <em> zu verwenden. Ein wahrhaft bedeutsames HTML-Element gibt es für fremdsprachliche Wendungen nicht. Man kann sich mit einem <span> behelfen. (In einer perfekten Welt unterstützt auch der Internet Explorer den Attribut-Selektor und die Formatierung kann ohne Klasse kontrolliert erden.)
Markup: Ein Redner <span lang="fr" class="fremdsprache">par exellence</span>

Kursiv hat viele Bedeutungen. Verwendet man zur Textauszeichnung semantisches Markup verleiht man seinem Text Bedeutung über die visuelle Ausgestaltung hinaus. Da die Formatierung nicht allein an die optische Präsentation geknüpft ist, steigt der Informationswert. Im Markup steckt mehr drin. Durch diese Meta-Information kann der Text von einem sprachgestützten Browser besser vorgelesen werden. Darüber hinaus wird der Text durch logische, unterscheidbare Markup-Muster maschinell vielfach verwertbar.

Der Zweifel: Sagt mein Markup das, was ich meine?

Die Grundlagen von semantischem Code sind schnell verstanden und verinnerlicht. Wenn man die richtigen Fragen stellt, bringt man seinem Markup geschwind bei, klar und deutlich zu sprechen. Doch nicht immer ist die Entscheidung für das bestmögliche HTML-Element so einfach, wie bei Überschriften, Listen oder Zitaten. Nicht immer findet man auf die Frage “Was will ich kommunizieren?” so leicht eine Antwort wie in unserem Kursiv-Beispiel.

Bei der Gestaltung von komplexen Websites gibt es für viele Seiten-Elemente oft kein klar überlegenes HTML-Element. Entmutigt nimmt unser heldenhafte Web-Entwickler ein paar <div>- oder <span>-Elemente und denkt an schönere Dinge – Farbe, Größe, Platzierung. Das Aussehen eben. Doch zwei Tage später ist das nuschelnde Markup schon zum Problem geworden. Ein zweiter Webstandards-Held will am Code arbeiten. “Hey, was redet dein Markup denn jetzt schon wieder?” Blöde Frage.

Das Werkzeug ist eben nicht perfekt. Doch auch wenn HTML in vielerlei Hinsicht umständlich zu handhaben ist, muss das damit gefertigte Endprodukt lange nicht barock und unüberschaubar sein. Mit etwas Routine kann man sich mit den Unzulänglichkeiten ganz gut arrangieren und das Beste rausholen. Gerade in schwierigen Situationen gilt: Zweifeln, aber nicht verzweifeln, die Lösungsmöglichkeiten überdenken und dabei Effizienz und Vorteile im Blick behalten.

Hierzu ein Beispiel.

Beispiel Navigationspfad

Home > Ebene 1 > Ebene 2

Die Breadcrumb-Navigation, die über einen “Sie sind hier”-Pfad den Weg durchs Web-Angebot nachzeichnet und klar den Standort ausweist, ist der Klassiker unter den Navigationsinstrumenten. Seit den Anfängen des Web setzen Kataloge wie Yahoo den Navigationspfad als Orientierungsmittel ein. Usability-Experten wie Jakob Nielsen oder Steve Krug rühmen die intuitive Bedienung. Dennoch gibt es für dieses elementare, gekrönte Navigationsmittel kein HTML-Element, welches die Struktur adäquat abbilden könnte. Die Auszeichnung im Code ist relativ frei wählbar. Das Markup soll aber – so das hehre Ziel – möglichst viel Bedeutung transportieren. Fangen wir also an zu zweifeln.

(Entwarnung: Nicht zweifeln müssen wir beim Aussehen. Jedes der folgenden Beispiele kann per CSS in einen bezaubernden horizontalen Navigationspfad umgewandelt werden. Hier denken wir über Struktur nach, nicht über Design.)

Navigationspfad als <div>-Container

<div id="navpfad">
Home &gt; <a href="">Ebene 1</a> &gt; <a href="">Ebene 2</a>

</div>

Zweifel: Besteht ein Navigationspfad nicht aus mehreren Links? Ist eine Breadcrumb-Navigation – wie andere Navigationsinstrumente auch – nicht eine Liste? Sollte man eine Liste nicht als Liste <ul> markieren?

Navigationspfad als unsortierte Liste <ul>

<ul>
<li>Home &gt; </li>
<li><a href="">Ebene 1</a> &gt; </li>
<li><a href="">Ebene 2</a></li>

</ul>

Zweifel: Besteht eine unsortierte Liste nicht aus gleichwertigen Einträgen? Sind die einzelnen Ebenen wirklich gleichwertig? Stellt ein Navigationspfad nicht ein Weg durch das Internetangebot dar?

Navigationspfad als nummerierte Liste <ol>

<ol>
<li>Home &gt; </li>

<li><a href="">Ebene 1</a> &gt; </li>
<li><a href="">Ebene 2</a></li>
</ol>

Zweifel: Bringt mich die Abfolge (1.,2.,3. …) wirklich weiter? Sollte der Pfad nicht die Site-Hierarchie abbilden? Gibt für eine hierarchische Struktur nicht eine adäquate HTML-Syntax?

Navigationspfad als verschachtelte Liste <ul>

<ul>
<li>Home &gt; 

<ul>

<li><a href="">Ebene 1</a> &gt;
<ul>
<li><a href="">Ebene 2</a>
</li></ul><!-- Ende Ebene 2 -->

</li></ul><!-- Ende Ebene 1 -->
</li></ul><!-- Ende Home -->

Zweifel: Steigt jetzt noch einer durch? Das ist zwar schlau ausgedacht, nur: bringt mir diese Markup-Suppe irgendeinen Vorteil?

Probieren wir also etwas ganz anderes.

Navigationspfad als Definitionsliste <dl>

<dl><dt>Sie sind hier:</dt>
<dd>Home &gt; </dd>
<dd><a href="">Ebene 1</a> &gt; </dd>

<dd><a href="">Ebene 2</a></dd>
</dl>

Zweifel: Durch die Definitionsliste muss ich meiner Breadcrumb-Navigation ein “Sie sind hier” voranstellen. Semantisch akzeptabel, aber: bin ich mit meinen Besuchern überhaupt per Sie? Das Markup baut zwar eine klare Beziehung zwischen den Elementen auf. Doch auch hier wird wieder keine Hierarchie kommuniziert, right? Zurück auf Los.

Wenn man semantisches Markup in sein Denken und in seinen Workflow integriert, verfolgen einen schnell die Geister, die man rief:

  • In welchem Element steckt mehr Bedeutung drin?
  • Was gibt mir bessere Möglichkeiten zur Gestaltung mit CSS?
  • Welche Markup-Variante spart mehr Code?
  • Habe ich den Inhalt mit einem HTML-Element umgedeutet, nur damit ich kein div verwenden muss?
  • Welche Variante ist für Textbrowser und Screenreader am besten?
  • Was passiert mit meiner ausgeklügelten Markup-Struktur, wenn weitere Inhalte hinzukommen?

Nur nicht verzagen. Wie unser Breadcrumb-Beispiel gezeigt hat, ist oft keine Möglichkeit perfekt, jede ist streitbar. Sogar die scheinbar schlichtesten HTML-Elemente wie das p können lebhafte Debatten auslösen (“When to p?”). Nichtsdestotrotz: Es lohnt sich immer wieder aufs Neue, die Herausforderung anzunehmen und mit sich selbst und anderen über das Pro und Contra zu streiten und sich dann für das beste Element zu entscheiden. Eine ausführliche Diskussion zur semantischen Auszeichnung eines Navigationspfades findet sich bei Dan Cederholm:

Der Profit: Warum ist semantisches Markup gut?

Spätestens jetzt fragt sich jeder halbwegs vernünftige Mensch, warum das Ganze? Haben diese Webstandards-Typen nichts Besseres zu tun? Spülmaschine ausräumen zum Beispiel? Zurück also zu den 1000 guten Gründen. Das Streben nach semantischem Code ist kein drolliger Zeitvertreib, sondern stellt sich schnell als Zeitersparnis heraus.

This is not done for purposes of theory, but to gain real world benefits including [...] easier site maintenance. (Zeldman 2003:174)

Drei Regeln für semantisches Markup:

  1. Lerne die HTML-Elemente kennen. Es sind nicht viele. Und es sind einige interessante Typen dabei. (Selfhtml-Sidebar)
  2. Stell die Frage nach der Bedeutung. Diskutiere. Wähle weise.
  3. Letzter Ausweg: Nimm ein div-oder span-Element. Gib ihm einen bedeutungsvollen, inhaltsbezogenen Namen.

Gerade in großen Projektteams, in denen mehrere Menschen am Code arbeiten, beschleunigt semantischer Code die Arbeitsprozesse und reduziert Abstimmungsrunden auf ein Minimum. Der Code ist durch seinen stringenten, logischen Charakter leichter lesbar und fast selbsterklärend. Davon profitiert nicht zuletzt die eigene Faulheit.

Doch nicht nur egoistische Gründe sprechen für semantisches Markup. Im Rahmen der der Interview-Serie “Falling in Love with CSS” hat Vorsprung durch Webstandards Web-Entwickler gefragt: “Why should people write semantic markup?”

Die eigennützigsten, selbstlosesten, coolsten und idealistischsten Gründe für semantisches Markup:

Die meistgenannten Antworten Nennungen
we can do more things with it / more powerful 14
It will make your life easier / good for personal laziness / you are faster / you can recyle your code 14
content matters / code becomes more meaningful and human readable 9
a craftsman should care not only for what he makes but also for his tools 7
better for search engines 7
more comfortable for users / smaller documents 6
more accessible 6
why not 4
morally and semantically superior! / cool 2

Die überzeugendsten Antworten im Wortlaut

Well-structured markup is like a beautiful love poem. It gets straight to the point – it wears its purpose on its sleeve. Simon Collision: Falling in love with CSS

If pages are marked up in a meaningful manner then they become more human-readable as well as more machine-readable (search engines, parsers, screen readers). Everyone’s a winner. Richard Rutter: Falling in love with CSS

If you care at all about forward-compatibility, about ideas and words lasting into the future, about making your content available to as wide a range as possible of all people and devices, about the ability of machines to read and at least partially understand your content and how each piece relates to other pieces, about how search engines rank your pages and allow discovery by others, and about using a tool how it was intended to be used – then it makes sense to create documents described with the most well-structured, semantic markup possible today. Douglas Bowman: Falling in love with CSS

There are many good and noble reasons to write well structured markup but from a purely business point of view it just makes sense. John Oxton: Falling in love with CSS

Because it’s what the cool kids do.
Patrick Griffiths: Falling in love with CSS

Fazit

Nicht immer liegt die Spannung im abweichenden Verhalten. Beim Schreiben von semantischem Markup entsteht der Kick, wenn man sich an die Regeln hält.

Bibliografie

Clark, Joe. 2005. Semantics.
Joe Clark stellt sich in seiner typischen Art quer und teilt Zettel aus, um der Frage “Was ist Semantik?” nachzugehen.
Holzschlag, Molly. 2005. The Meaning of Semantics (Take I and Take II).
Molly erklärt einfach und verständlich, worum es bei semantischem Code geht. Sich selbst schont sie dabei nicht.
Kaiser, Shirley E. 2005. Semantics, HTML, XHTML, and Structure
Kompakte Zusammenstellung und Kommentierung der wichtigsten HTML-Elemente. Besonders nett: Die FAQ-Sektion
Langridge, Stuart. 2005. DHTML Utopia: Modern Web Design Using JavaScript & DOM
Mit modernem standardkonformen JavaScript kann man viel Gutes tun. Grundvoraussetzung: Semantisches HTML.
Shea, Dave. 2005. Who Cares about Semantics Anyway?.
Dave Shea mit seiner Definition von Semantik. Und weil die so kurz ist, stellt er noch einen Markup-Guide dazu.
Zeldman, Jeffrey. 2003. Designing with Web Standards.
Weil semantischer Code mehr bedeutet, als nur <i> gegen <em> auszutauschen, erklärt Jeffrey Zeldman – auf seine lässige Art – nicht, wie man mit Tofu feine Dinge kocht, sondern worauf es bei modernen Websites ankommt.

Bei Vorsprung durch Webstandards weiterlesen

Suche

About

"Vorsprung durch Webstandards" ist ein Webzine zu Webstandards, Barrierefreiheit und Usability. In loser Folge erscheinen hier theoretische Texte, praktische Tipps und hilfreiche Links zum Thema.

Twitter

Follow Vorsprung on Twitter

Classics

Falling in love with CSS

I love CSS

alle Interviews

Updates

Feed Neue Texte als RSS-Feed

Autoren

Heike Edinger, heike.edinger at gmail.com

Timo Wirth, timo.wirth at gmail.com