Lea Verou bedient sich ihres eigenen Online-Präsentationssystems, das er hier als Demo zu sehen gibt und hier da zugehörige Github-Projekt. Unter cubic-bezier.com hat Lea übrigens ein Tool zur Verfügung gestellt, um die CSS3-Funktion cubic-berzier() mit Leben zu füllen. Sehr cool. Was die Funktion macht steht widerum in ihrer Präse. Lea kennt man übrigens von ihrer CSS Patters Demo, zum Beispiel.

Aus den Slides von Divia Manians ist mir ganz dringend compass im Ohr geblieben, ein Framework, das auf SASS aufsetzt.

Ebenfalls auf der fronteers wurde mir dieser hervorragende Link mit incredibly useful CSS snippets zugespielt. Was mehr als zutreffend ist: bitte sofort ausdrucken!

Wer viel mit Browsern und Tests zu tun hat, der kann sich ja mal Browserstack anschauen, für das John Resig die Werbetrommel rührt. Dort bekommt man Testbrowser in virtuellen Maschinen in der Cloud…

Da ist ein Eisbär im Raum?

Im Moment gibt es wieder viel zu lernen, in Sachen CSS. Da sind zunächst die vielen neuen Dinge, die CSS3 bringt. Durch die derzeit rasante Browserentwicklung, Polyfills oder einfache Fallbacklösungen kann man vieles davon schon heute oder wenigstens morgen gebrauchen. Dazu kommen die Learnings aus einigen Jahren intensiven Einsatzes von CSS, seit der internationalen Ächtung des Tabellenlayout ist viel passiert.

Seit CSS dem style-Attribut entwachsen ist, unterlag es lange Zeit einer eher langsamen Entwicklung. Gehemmt durch den Internet Explorer hat es ewig gedauert, bis sich CSS 2(.1) überhaupt durchgesetzt hat. Man hat lange Zeit eher mit den gegebenen Umständen hantiert, anstatt CSS weiter zu entwickeln. Die floats lösten die Tabellen ab, die CSS Hacks beherrschten die Szene lange, machten zweigleisige Entwicklung für potente und für beschränkte Browser möglich. Das Set an Techniken hat sich aber in der Menge kaum verändert, vielmehr lernten wir immer besser damit umzugehen. Dabei sind aber auch viele Standardlösungen entstanden, die heute einer genaueren Prüfung unterzogen werden müssen.

Our best practices are killing us!

Nicole Sullivan (die, nicht die) tritt derzeit mit einem Vortrag unter diesem Titel auf, den ich sehr beeindruckend finde, weil er so sehr das trifft, was ich derzeit selbst in der Praxis feststelle. Viele der best practices, die in den letzten Jahren ersonnen, gepaukt und umgesetzt wurden, klingen gut, haben sich aber in den Jahren ihres Einsatzes vielleicht gar nicht bewährt. Andere wurden von der Entwicklung überholt, wurden zur Angewohnheit. Um mal ein klassisches Beispiel aus einem anderen Bereich zu bringen: wenn Sie <script>-Blöcke in einem HTML-Document nutzen, umgeben sie den Code dann auch noch mit HTML-Kommentarzeichen? Eine Technik, die heute lange nicht mehr nötig ist. Trotzdem sieht man sie immer wieder. So geht es auch mit vielen Angewohnheiten in CSS.

Nicole Sullivan nennt viele Beispiele. Unter anderem findet sie:

• die Angabe von Schriftgrößen nicht in Pixel sei kontraproduktiv,

• etwas mehr Klassizitis wäre gar nicht so schlecht, da so lange Selektorketten vermieden würden,

• durch semantische Klassennamen würde der Codewiederholung der Weg bereitet,

• der Mythos, kein zusätzliches Markup für das Layout einführen zu dürfen, sei mehr als schädlich, da durch Container Layoutprobleme auf festgelegte Bereiche beschränkt werden könnten.

In der Praxis nicht bewährt

Da geht es ihr genau wie mir. Wenn man betrachtet, wie wirklich große Website-Projekte entstehen, stellt man fest, dass durch die genannten best practices Nötiges nur von einer Ecke des Projekts in die andere verschoben wurde. So kann man wunderbares, absolut semantisch reines HTML schreiben, ohne jegliche Layout-Divs, so klein wie nur irgend möglich, ob die Seite dadurch wirklich schneller wird? Oder übersichtlicher? Nun, das HTML natürlich schon, aber wenn wir uns anschauen, wieviel sich gegenseitig überschreibendes CSS benötigt wird, merkt schnell, das man die Komplexität nur verlagert hat. Miss Sullivans Beispiel: bei Facebook hatte man vor einem umfassenden CSS-Relaunch 706 CSS Dateien, in denen 261 Mal die gleiche Farbe blau definiert war. Do not repeat yourself?

Und dabei geht’s nicht mal darum, sich gegenseitig den schwarzen Peter zuzuschieben: Komplexität im CSS schadet allen Beteiligten, denn sie drückt auf die Performance. Mein Beispiel ist die tägliche Praxis. Bei einem großen Projekt wurden nahezu nach Lehrbuch beim Schreiben von HTML-Code (und Javascript^[1]) auf auf eine ganze Reihe best practices geachtet. Das hat zunächst mal dazu geführt, dass wir zwar schlankes HTML, aber ziemlich viel CSS (und Javascript) über die Leitungen schicken. Dabei ist die Menge an CSS und seine Komplexität eine direkte Folge der semantischen Strukturen im HTML. Aber wo im HTML bspw. nur wenige Klassen stehen, muss im CSS mit unendlich langen Selektorketten auf Elemente zugegriffen werden, was die Menge an CSS erhöht, die Geschwindigkeit des Renderings aber herabsetzt. Nach einigen Jahren ist diese Situation immer schlimmer geworden. Sie ist dabei kaum noch überschaubar, weil man praktisch nur noch mit dem Firebug entscheiden kann, welche CSS-Regel auf ein Element greift. Und die schiere Menge an Code macht es nicht besser. Abhilfe schafft da oft, einfach mal eine Klasse ins HTML zu schreiben, die direkt angesteuert wird. Und die darf dann vielleicht auch mal “blue” heissen, naja, vielleicht besser “main-color”.

CSS Refactoring?

Will man sich aber, mindestens in Teilen nun aber von dieser Praxis abwenden, dann hat man jetzt den GAU, den man eigentlich vermeiden wollte: Änderungen an der Codebasis und am CSS. Zumindest kann man das Nutzen, um die IE6-Unterstützung endgültig zu droppen und so das ganze CSS etwas zu modernisieren. So stehen nun vieler Orten viele Änderungen in Sachen CSS an. Neues hinzufügen, alte Zöpfe abschneiden. Alte Projekte auf den aktuellen Stand heben.

^[1] Noch ein Nebensatz zur Rolle von Javascript: dies wurde erstaunlicherweise viel zu oft genutzt, um die selbst gesetzten Grenzen bei HTML und CSS zu überwinden oder umgehen. Hüstel…

-moz-background-size

Da ist Mozilla ja etwas hinterher gewesen, denn die Größe des Hintergrundbildes anzupassen gestatten andere Browser schon länger (Opera ab 9.5, Safari3 und Konqueror). Dabei lässt sich das Hintergrundbild von der -moz-background-origin auf verschiedene Arten vergrößern und/oder verkleinern. Neben Angaben in Länge oder Prozent, sind auch Schlüsselwörter wie auto, contain (so groß wie möglich, wenn das Bild kleiner als die Größe des Container ist) und cover (so klein wie möglich, wenn das Bild größer ist) erlaubt. Die letzten beiden Schlüsselwörter sind bisher firefoxproprietär.

image-rendering

Passend dazu wird die Eigenschaft image-rendering eingeführt, eine Analogie zu Microsofts -ms-interpolation-mode. Während man bei M$ aber zwischen bicubic und nearest-neighbour wählen kann, bietet Mozilla vier Werte an: auto, optimizeQuality, optimizeSpeed und -moz-crisp-edges. Wobei im Moment zumindest gilt: auto = optimizeQuality und optimizeSpeed = -moz-crisp-edges. Jedenfalls soll damit dem Browser eine Renderingmethode für vergrößerte oder verkleinerte Bilder an die Hand gegeben werden.

-moz-linear/radial-gradient

Ebenfalls neu und im Hintergrund tätig sind -moz-linear-gradient und -moz-radial-gradient. Firefox stellt damit die Möglichkeit zur Verfügung, Farbverläufe zu generieren, die sich in der Verlaufsrichtung genauso beeinflussen lassen, wie in den Verlaufslänge. Außerdem können beliebig viele Vias bzw color-stops agebeben werden, d.h. man kann auch (wenn man das will) Regebogenverläufe erzielen. Democode dazu:

background: -moz-linear-gradient(left, right,
    from(red),
    color-stop(16%, orange),
    color-stop(32%, yellow),
    color-stop(48%, green),
    color-stop(64%, blue),
    color-stop(80%, indigo),
    to(violet));

Neben den Farbschlüsselwörtern funktionieren natürlich auch Hexoces, rgb() und (Achtung!) auch rgba(), also auch Transparenzen.

Dieses Feature gibt es übrigens auch schon bei anderen Browsern, nämlich seit IE 5.5 als filter: progid:DXImageTransform.Microsoft.Gradient() und auch in Safari 4, als -webkit-gradient(linear,…) (man ist sich mal wieder nicht über die Syntax einig).

Weitere Mediaqueries

Bereits ab Version 3.5 unterstützt Firefox die CSS3 media queries, womit man Stylesheets anhand bestimmter Eigenschaften des Mediums auswählen kann, auf dem eine Website angezeigt wird. Einige Berühmtheit hat dieses Feature bereits durch das iPhone erlangt, denn mit <link media="only screen and (max-device-width: 480px)" href="../iphone.css" type="text/css" rel="stylesheet"/> kann man eben ein Medium ansteuern, dessen maximale Darstellungsbreite 480px ist, also bspw. das iPhone. Solche queries kann man über viele Eigenschaften machen, bspw. Farbtiefe, Seitenverhältnis des Bildschirms, dessen Höhe und Breite, die Höhe und Breite des Viewports und einige mehr.

Firefox ab 3.6 kann noch ein paar mehr, mozilla spezifische Queries verstehen und auswerten. Damit lassen sich tatsächlich sehr spezielle Dinge über das genutzte Medium erfahren, zum Beispiel, ob die Website unter einem ungethemeten Windows angezeigt wird (moz-windows-classic) oder unter OS X mit „Graphite” Erscheinungsbild (-moz-mac-graphite-theme) oder eben – und das wirds m.M. nach interessant – ob ein Touchscreen vorliegt: -moz-touch-enabled. Mit letzterm könnte man bspw. auch für Touchscreens das normale CSS verwenden, aber Buttons einfach ein wenig vergrößert darstellen. Da ist noch einiges drin… zur Zeit aber nur proprietär für Firefox.

:indeterminate

Ich geb hier mal zu, dass ich nicht wusste, dass man mit Javascript seit Firefox 3.2 eine Checkbox den Zustand „indeterminate” zuweisen kann document.getElementById(”check1″).indeterminate = true;, oder was es damit auf sich hat (wenn man das Beispiel sieht, ist alles klar). Ab FF3.6 kann man diesen Zustand über eine CSS-Pseudoklasse nutzen, also bspw. die Hintergrundfarbe des Checkbox ändern.

WOFF

Und last but not least unterstützt Firefox 3.6 das Fontformat WOFF (Web Open Font Format). WOFF erklärt sich so:

WOFF (Web Open Font Format) is a new web font format developed by Mozilla in concert with Type Supply, LettError, and other organizations. It uses a compressed version of the same table-based sfnt structure used by TrueType, OpenType, and Open Font Format, but adds metadata and private-use data structures, including predefined fields allowing foundries and vendors to provide license information if desired.

developer.mozilla.org

Ich sag mal Erik Spiekermann befürwortet das neue Format und es sieht so aus, als das dies der Weg aus der Linzenzfalle beim einbetten von Schriften via @font-face ist.

Natürlich ist es mal wieder die Internet-Explorer-Familie, die extreme Perdormanceprobleme aufweisen, aber auch sämtliche andere Browser bekleckern sich im Umgang mit der noch recht jungen Technologie kaum mit Ruhm. FOUT – flash of unstyled text ist dabei noch das kleinste Problem, wenn die Fontdateien nicht schnell genug vom Server geliefert werden. In IEs wirkt sich das noch schlimmer aus: bis zum Download des Fonts zeigt Bill Gates Rache gar nichts an. In anderen Browsern bleiebn nur die Textteile, die mit @font-face gerendert werden sollen unsichtbar, Firefox zeigt die Ausweichschrift(en) an.

Solchen (und den anderen im Text genannten) Performancefallen kann man natürlich mit Caching, Zipping und ähnlichzen Techniken begegnen. Ob man sich aber den Aufwand leisten will, bereits zum jetzigen Zeitpunkt, ich stelle das mal in Frage…

@font-face {
  font-family: 'Graublau Web';
  src: url(GraublauWeb.eot);
  src: local('Graublau Web Regular'), local('Graublau Web'),
         url(GraublauWeb.otf) format('opentype');
}

Puh. Ist das gekärt.

Mit @font-face lassen sich Schriften in Webseiten einbetten. Machen Sie das!

Ok, es ist soweit, mit dem neuen Firefox 3.5 (und Safari 4 und Opera 10beta), steht immer mehr Nutzern unserer Websites Fontembeddingdownloading¹ zur Verfügung. Damit widerum steht der flächendeckenden Umsetzung typographisch ordentlich gestylter Websites nicht mehr viel im Weg, ausser natürlich die IE-Familie, aber die ignorieren wir hier einfach einmal.²

Und so geht’s

Das obige Beispiel nutzt das Embedding, der Code dafür sieht ungefähr so aus:

@font-face {
    font-family: Kaffeesatz;
    font-weight: normal;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
h1 {
	font: normal 3em/120% Kaffeesatz, sans-serif;
	text-shadow: 1px 1px 1px #eee;
}

Der genutzte Font ist die unter CC Lizenz stehende Kaffeesatz. Der Code ist vielleicht nicht ganz selbst erklärend: mit @font-face legen wir selbst eine Font fest, den Namen der font-family kann man dabei frei wählen, ein dem Font nahe stehender Name empfiehlt sich natürlich. Als src wird der Pfad zum OTF- oder TTF-File angegeben, danach noch das format. Fertig. Damit steht uns die font-family „Kaffeesatz” zur weiteren Nutzung zu Verfügung. Das H1 macht auch gleich Gebrauch davon, noch ein wenig versüsst mit etwas CSS3-text-shadow (wenn wir auf den IE sch…sen, dann aber richtg).

Mehr Gewicht, bitte

Folgendes ist zu beachten: wir haben bis hier nur den Font für die font-weight normal definiert. Wollen wir eine bolde Schrift, muss ein Font dafür embedded werden, und zwar bspw. so:

@font-face {
    font-family: Kaffeesatz;
    font-weight: normal;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: bold;
    src: url(fonts/YanoneKaffeesatz-Bold.otf) format('opentype');
}
h1 {
	font: normal 3em/120% Kaffeesatz,sans-serif;
	text-shadow: 1px 1px 1px #eee;
}
h2 {
    font: bold 2em/120% Kaffeesatz, sans-serif;
    text-transform: uppercase;
}

In diesem Falle würden die H2s bold gesetzt, da wir hierfür YanoneKaffeesatz-Bold.otf embedded haben. Ähnliches können wir nun auch mit font-style: italic anstellen.

Nochmal zurück zur Fettung: Safari kann einige Fettungsstufen mehr anzeigen als Firefox. Unterstützt wird eine genauere Abstufung des Fettungsgrades, wenn man bspw. einen Font hat die Kaffeesatz. Das kann dann so aussehen:

@font-face {
    font-family: Kaffeesatz;
    font-weight: 100;
    src: url(fonts/YanoneKaffeesatz-Thin.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 300;
    src: url(fonts/YanoneKaffeesatz-Light.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 400;
    src: url(fonts/YanoneKaffeesatz-Regular.otf) format('opentype');
}
@font-face {
    font-family: Kaffeesatz;
    font-weight: 700;
    src: url(fonts/YanoneKaffeesatz-Bold.otf) format('opentype');
}

Das geht sicherlich auch mit keywords wie „light” oder „bolder” etc.

Das Fontrendering unterscheidet sich mitunter, links Firefox, rechts Safari 4 (Mac).

Fonts von der Platte zuerst

Was ja auch angehen kann, ist dass man eher einen Font nutzen möchte, der sowieso schon lokal vorhanden ist und nur wenn dieser nicht vorhanden ist, will man einen Download anbieten. Geht auch, wie man bei John Dagget nachlesen kann, mit der Eigenschaft „local”:

@font-face {
  font-family: NeueHelvetica;
  src: local("Helvetica Neue"),
       local("HelveticaNeue"),
       url(fonts/MgOpenModernaRegular.ttf);
}

Hier sind zwei local angegeben, über diese Liste wird iteriert, genauso wie in der normalem font-family Zuweisung, wo die Schriften durch Kommata getrennt werden (das diese Zusammenstellung von Namen nicht immer ganz einfach ist, lesen wir bei Herrn Preidel).

Und nun?

Natürlich sollte man nur Schriften nehmen, die man auch fürs embedding benutzen darf, sonst gibt’s schnell Lizenzärger. Hier gibt’s ein paar freie Schriften, die das ausdrücklich zulassen. Ach ja und zum guten Schluss, sollte man font-size-adjust auf keinen Fall vergssen.

Updates

¹⁾ Von „Embedding“ zu sprechen ist eigentlich nicht richtig, weil der Font tatsächlich auf den Rechner des Nutzers heruntergeladen wird. Das schlägst sich natürlich auch in der Größe der Website nieder und ist auch für die Lizenzfrage nicht unerheblich.

²⁾ Na gut, ich hab noch einen Link aus meinen Bookmarks geangelt, der mehr in Sachen IE verrät.

Corynnbacterium Diphtheria (Foto: CDC).

Wir wissen ja schon lange, dass valides HTML noch kein gutes HTML ist. Kalter Kaffee. Sehen wir dabei einmal vom durchaus validem Tabellenlayout ab, sind die größten Feinde mangelnde semantische Auszeichnung und in deren Schlepptau immer wieder DIVterie, soll heissen: übermäßige Benutzung von DIV-Containern, wo andere Elemente angebrachter wären. Bekannte Nebenwirkung dieser Krankheit sind übrigens Klassizismus, IDologie und natürlich VerSPANnung.

Zugegeben: DIVterie ist durchaus verbreitet (ich selbst zeichne für eine Seite verantwortlich, die deutlich darunter leidet) und auch irgendwie ansteckend. Infiziert von einem CSS-Framework kann man sich schon mal anstecken. Dem begegnet HTML5 übrigens (demnächst), in dem ein ganzes Rudel semantisch bedeutungsvoller Block-Level-Elemente eingeführt werden, die demnächst so manches DIV ersetzen könnten. Das würde auch ein wenig gegen die Nebenwirkungen helfen, aber soweit sind wir wohl noch nicht.

Wo ist eigentlich das Problem

DIVterie kann man von zwei Seiten betrachten: zunächst einmal ist ein DIV im Zusammenhang ziemlich bedeutungslos, ein Container, in den man Sachen packt, von denen dann niemand weiss, zu was sie gehören und warum sie dort herumlungern. Das kann man manchmal sogar brauchen, meist wäre es aber sinnvoll, wenn man ein Element einsetzt, ihm auch eine Bedeutung zu verleihen. Ja, wenn man ein Element einsetzt. Denn man kann und muss DIVterie natürlich auch noch von einer anderen Warte aus beleuchten: zuviele DIVs, Klassen, IDs machen den Code fett, das HTML wächst krankhaft an, das zugehörige CSS gleich mit. Schwerer Code ist langsamer Code. Man mag das in Zeiten von Highspeed-DSL-Anschlüssen vernachlässigen wollen, aber im professionellen Umfeld kann man das nicht: die Menge an Code ist letztendlich so hoch, dass es auf jedes gesparte Zeichen ankommt.

Was tun?

Beiden Betrachtungsweisen begegnen wir mit einer einfachen Regel:

Prüfe zunächst, ob Du wirklich ein Element brauchst. Wenn Du Dir sicher bist, dass Du eines brauchst, prüfe alle Möglichkeiten kein DIV zu verwenden. Wenn all das nichts geholfen hat…

Das ist jetzt schwieriger, als es klingt. Hilfreich ist es übrigens, wenn man ein Bild von der Seite oder besser noch den Seiten, die man bauen will, hat. Nein, keinen Photoshop-Ausdruck, sondern eine Skizze, auf der man die benötigten Elemente (bspw. als Kästen) anordnet. Schon in dieser Phase lassen sich DIVs vermeiden. Wenn man einfach drauf loscodet ist man immer in Gefahr noch hier und da schnell noch einen Container drum zu ziehen, eine Klassen oder gar ID dranzuschreiben.

Ein Beispiel

Hier mal ein Codeschnipsel als schlechtes Beispiel, bitte nicht nachmachen:

<div class="container clearfix">
    <div class="teaser">
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" class="img_left" />
        <h3 class="text"><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><span class="bold">Lorem ipsum:</span> Dolor sit amet</a></h3>
        <div class="teasertext">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</div>
    </div>
    <div class="teaser">
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" class="img_left" />
        <h3 class="text"><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><span class="bold">Lorem ipsum:</span> Dolor sit amet</a></h3>
        <div class="teasertext">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</div>
    </div>
</div>

Dazu würde folgendes CSS passen (es passt auch in der Fehlerhaftigkeit, also bitte nicht als Vorlage verwenden):

div.container {
    border: 1px solid #000;
    color: #000;
    font-size: 12px;
    margin: 0;
    padding: 0;
}

.container .teaser {
    margin: 10px;
}

img.img_left {
    float: left;
    margin: 0 10px 7px 0;
}

h3.text {
    font-size: 14px;
    font-weight: 400;
}

span.bold {
    font-weight: 700 !important;
}

.container .teaser .teasertext {
    font-size: 10px;
    line-height: 14px;
}

Geht so gar nicht! Geradezu klassisch übrigens, die Klasse “container”. Aber mal im Ernst: hier haben wir einen Container, der mehrere Text-Bild-Blöcke enthält, die den gleichen Aufbau haben. Und einen typischen Fall von DIVterie. Zunächst wäre zu überlegen, ob man nicht ein paar DIVs und ein paar Klassen loswerden kann. Möglicherweise so:

<div class="container clearfix">
    <div>
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
        <h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
        <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    </div>
    <div>
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
        <h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
        <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    </div>
</div>

Von oben nach unten: wenn wir davon ausgehen, dass der “Container” gebraucht wird, bspw. weil die Teaser eine inhaltliche Einheit dartellen und ggf. mit einer border umschlossen werden sollen, dann fällt zunächst das <div class="teaser"> auf. Gäbe es keine anderen DIVs in dem Block, wäre die Klasse überflüssig. Ebenso scheinen alle Bilder die gleiche Klasse zu haben. Dann weg damit. Das <h3 class="text"> war ja schon ein netter Versuch, die Klasse allerdings ist überflüssig und ausserdem ist “text” ein denkbar schlechter Klassenname. Weg bitte auch mit dem (zugegeben etwas konstruierten) <span class="bold">, dafür bitte <strong> verwenden. Ebenso falsch ist <div class="teasertext">, denn dort passt viel besser ein <p>. Das ist ja nun schon ein wenig kompakter, aber auch sinniger, wie ich finden muss. Alle Elemente sind immer noch voll per CSS ansprechbar und können genauso gestyled werden wie oben.

Passendes CSS sähe dann so aus:

.container {
    border: 1px solid #000;
    color: #000;
    font-size: 10px;
    line-height: 14px;
}

.container div {
    margin: 10px;
}

.container img {
    float: left;
    margin: 0 10px 7px 0;
}

.container h3 {
    font-size: 14px;
    font-weight: 400;
}

Zur Erläuterung: Durch die bessere semantische Auszeichnung haben wir auch im CSS schon viel gewonnen. Ich mühe mich immer redlich eine Balance zwischen generellem und spezialisierten CSS-Anweisungen zu finden, es stellen sich also häufig Fragen wie: »sind vielleicht alle H3 auf der Seite gleich, oder nur das in dem Container?«. Das ist im zweiten CSS-Schnipsel besser umgesetzt. Eine Formatierung des <p> ist z.B. – vorrausgesetzt es wird an anderer Stelle nicht umformatiert – gar nicht nötig, da es schon die geschickt gewählten Eigenschaften des Containers erbt (zugegeben: man müsste sich ggf. noch um margin und padding kümmern). Ebenso sind die übertriebenen Klassenverkettungen (wie .container .teaser .teasertext) entfernt.

Das ist nun schon ganz guter Code, geht aber vielleicht auch noch besser. Eben schrieb ich, wir hätten es mit Container, der mehrere Text-Bild-Blöcke enthält, die den gleichen Aufbau haben zu tun. Klingt fast nach einer Liste von Text-Bild-Blöcken. Wenn man will, kann man sich also komplett aller DIVs entledigen:

<ul class="teaserlist">
    <li>
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
        <h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
        <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    </li>
    <li>
        <img alt="Lorem ipsum dolor sit amet" title="Lorem ipsum dolor sit amet: velit esse cillum dolore" src="loremipsum.jpg" />
        <h3><a href="loremipsum.html" title="Lorem ipsum dolor sit amet"><strong>Lorem ipsum:</strong> Dolor sit amet</a></h3>
        <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.</p>
    </li>
</ul>

Das CSS dazu:

.teaserlist {
    border: 1px solid #000;
    color: #000;
    font-size: 10px;
    line-height: 14px;
    list-style: none;
    margin: 0;
    padding: 0;
}

.teaserlist li {
    margin: 10px;
}

.teaserlist img {
    float: left;
    margin: 0 10px 7px 0;
}

.teaserlist h3 {
    font-size: 14px;
    font-weight: 400;
}

Beim CSS ist der Gewinn nicht mehr so groß, aber dafür ist der HTML-Code semantisch ausgezeichnet und schlanker als der Ausgangscode. In meinen Augen besserer Code.