Gregor Honsel mosert bei Heise Technology Review über die Breitbildschirme:
Es gibt gute Gründe für das klassische 4:3-Format. Textdokumente und die meisten Webseiten sind nun einmal eher hochformatig. Je flacher der Bildschirm, desto mehr muss man scrollen. Und werden die Zeilen zu breit, leidet die Lesegeschwindigkeit, weil das Auge beim Zeilenwechsel den Anfang der nächsten Zeile schlecht wiederfindet. Es hat schon seinen Grund, dass Bücher und Zeitschriften im Hochformat gedruckt werden.
Sehr richtig. Aber bei Webseiten übersieht er hier Etwas. Allerdings Etwas, das auch die meisten Webdesigner übersehen. Warum sind Textdokumente eher im Hochformat? Weil sie klassischerweise auf Papier ausgedruckt werden. Und wegen des Problems, bei langen Zeilen die nächste zu finden, sind Bücher und Zeitschriften i.d.R. eben im Hochformat gedruckt. Das ist sinnvoll so. Aber wie sieht das mit Webseiten aus? Werden Webseiten überhaupt gedruckt? Nun, das kann vorkommen. Und wenn sie gedruckt werden, dann sollten sie in der Tat im Hochformat gedruckt werden. Aus den bekannten Gründen. Aber die Mehrheit der Webseiten wird wohl eher nicht gedruckt, sondern am Bildschirm angesehen. Nun hat nicht Jeder die Möglichkeit, den Bildschirm mal eben hochkant zu stellen. Dies ändert sich zwar gerade durch die Smartphones, aber noch gibt es viele Notebooks mit eher breiten als hohen Bildschirmen. Selbst ein 4:3 Bildschirm ist nun mal breiter als hoch. Trotzdem bleibt das Problem der langen Textzeilen natürlich bestehen.
Was macht der Webdesigner? Er legt die Schriftgröße fest, und davon abhängig die Breite der Seite. Mal davon abgesehen, dass die meisten von Webdesignern gewählten Schriftgrößen für ältere Menschen eher ungeeignet, weil viel zu klein sind, ergibt sich dadurch jedoch ein unschönes anderes Problem. Wie Gregor Honsel richtig schreibt, nimmt die Zahl der 4:3 Monitore ab, und die Zahl der Breitbildschirme zu. Also ergibt sich die Frage, wie bekomme ich eine eher schmale Seite auf einen eher breiten Bildschirm. Wenn man Designer-zentriert denkt, dann packt man eben die schmale Seite in die Mitte des Bildschirms und füllt den großen Rest mit einem einheitlichen Grau. Das befriedigt zwar den Designer, weil jetzt seine schön und mit viel Arbeit designte Seite ganz besonders gut, weil weit und breit alleinstehend, präsentiert wird. Aber es befriedigt den Betrachter nicht unbedingt, weil damit eine Menge Platz verschwendet wird. Der schöne große und vor Allem breite Bildschirm wird kaum zur Hälfte genutzt. Was für eine Verschwendung. Wenn man Konsumenten-zentriert (Betrachter-zentriert) denkt, dann fällt diese Verschwendung unangenehm auf. Nun kann man zwar die Seite vergrößern (die Vorstellung allein ist ein Graus für jeden Webdesigner, der sein Design mühevoll pixelgenau aufgebaut hat), und damit wird dann der Platz genutzt. Aber jetzt sind die Schriften riesig und die Zeilen wenige. Jetzt muss der Betrachter, wie Honsel schreibt, viel zu viel scrollen, um an den Inhalt zu kommen. Auch nicht befriedigend.
Und was, wenn der Designer zur Lösung des Problems die Seite nicht in der Breite fixiert, sondern den Browser einfach den vorhandenen Platz mit dem Inhalt füllen lässt? Dann wird der Inhalt so auf dem Bildschirm verteilt, dass kein Platz verschwendet wird. Heraus kommen sogenannte Fluid Layouts. So weit, so schön. Aber auf den breiten Monitoren werden nun die Zeilen zu lang, und es ergibt sich genau das von Honsel korrekt erkannte Problem mit dem Finden der nächsten Zeile. Jetzt stehen wir vor einem Dilemma: Entweder kurze Zeilen mit viel Verschwendung von Bildschirmfläche, oder lange Zeilen ohne Verschwendung, aber auf Kosten der Lesbarkeit.
Doch es gibt Abhilfe. Der zunächst einfachste Ansatz ist, einen Kompromiss zu finden zwischen Text in kompletter Bildschirmbreite und schmalen Textblöcken mit Platzverschwendung. Warum nur entweder-oder? Ein prozentualer Rand (margin) links und rechts entschärft das Problem etwas und sorgt gleichzeitig auf allen Bildschirmen für ein harmonisches Aussehen. Das Problem der langen Textzeilen wird dadurch allerdings nicht gelöst, nur leicht entschärft. Wie also machen?
Dazu schauen wir zunächst mal, wie man es bei Büchern oder Zeitschriften macht. Manche Bücher und praktisch alle Zeitschriften lassen ihre Textzeilen nicht über die gesamte Seitenbreite laufen. Stattdessen wird Etwas gemacht, das man Spaltensatz nennt. Diese Idee lässt sich grundsätzlich auch auf Bildschirme übertragen. Im ersten Ansatz mag man hier vielleicht an die Zeiten von html 3.2 denken und die Spalten in eine Tabelle gießen. Bei einem gegebenen Bildschirm kann dadurch ein durchaus ansprechendes Resultat erzielt werden. Das Problem dabei ist: Dem Webdesigner ist ja vielleicht ein Bildschirm gegeben. Aber dem Konsumenten sehr wahrscheinlich ein ganz anderer Bildschirm. Nehmen wir an, der Webdesigner hat einen heute üblichen Breitbildschirm von 1980x1080 Pixeln. Darauf hat er vielleicht seinen Text per Tabelle in 4 spalten verteilt. Jetzt kommt gemeinerweise der Konsument und will sich die Seite auf seinem Smartphone im Hochformat anschauen. Jetzt wird ein Design, das einen breiten Bildschirm voraussetzt, plötzlich in ein schmales Korsett geschnürt. Da bleibt dem Konsumenten die Luft weg. Und das nicht vor Freude.
Eine Analyse dieses Dilemmas klärt auf: Zunächst mal ist eigentlich die Frage nach Spalten ja oder nein, und wenn ja, wie viele, ganz und gar irrelevant. Relevant ist allein die Länge der Textzeilen. Wenn man diese Erkenntnis ganz konsequent in das Design der Seite einfließen lässt, kommt man zwangsläufig zu einer speziellen Form des CSS Mehrspaltenlayouts. Hier haben wir die Möglichkeit, zum Beispiel die Anzahl und/oder die Breite der spalten anzugeben. Die Anzahl der Spalten geben wir mit column-count an, die Breite der Spalten mit column-width. Es gibt noch einige andere nützliche Angaben, aber die lasse ich bei dieser Betrachtung einmal aussen vor. Wenden wir also die Erkenntnis, dass nicht die Anzahl der Spalten, sondern einzig die Länge der Textzeilen relevant ist, konsequent auf diese beiden Attribute an. Die Länge der Textzeilen ergibt sich automatisch durch die Breite der Spalten. Logischerweise gibt man also, wenn man die Breite der Spalten einigermaßen konstant halten will, die Breite und nicht die Anzahl der Spalten an. Man verzichtet also auf column-count und beschränkt sich auf column-width.
Aber man kann noch einen Schritt weiter gehen. Was genau an der Länge einer Textzeile relevant ist, ist nicht so sehr die Länge in Zentimetern oder Pixeln, sondern die Anzahl der Buchstaben in der Zeile. Nun gibt es zwar keine Maßeinheit in css, mit der man die Anzahl der Buchstaben angeben kann. Das wäre bei proportionalen Schriften, bei denen jeder Buchstabe eine andere Breite hat, auch nicht möglich. Die Anzahl genau festzulegen ist also nicht möglich. Es gibt aber einen Näherungswert: em. Dies entspricht der Breite des Buchstabens 'M', und zwar in der gerade gewählten Schriftgröße. Eine Angabe von column-width: 40em; würde also bedeuten, dass in dieser Spalte 40 mal der Buchstabe 'M' reinpassen würde. Die meisten anderen Buchstaben sind schmaler. In einer echten Spalte werden wir damit also mehr als 40 Buchstaben finden. Dennoch wird die Anzahl der Buchstaben in einer Zeile effektiv begrenzt. In der Praxis hat sich bei mir (nach meinem persönlichen Geschmack) eine Breite von 26em bewährt.
Was passiert nun mit einem Text wie diesem hier, wenn er auf einem sehr breiten Monitor dargestellt wird mit den voreingestellten Schriftgrößen? Nun, der Text wird in vermutlich 3 Spalten umgebrochen. Die Länge der Textzeilen ist begrenzt, der Text bleibt angenehm lesbar. Und was passiert, wenn die Schriftgröße vergrößert wird? Dann werden statt drei vielleicht nur zwei Spalten eingerichtet und der Text in zwei Spalten umgebrochen. Die Länge der Textzeilen bleibt in Etwa konstant, der Text bleibt lesbar. Und was passiert auf einem 4:3 Monitor mit vielleicht weniger hoher Auflösung? Dann wird der Text nur einspaltig umgebrochen. Ganz automatisch. Ausser, der Benutzer hat sich eine sehr kleine Schrift eingestellt, weil er Adleraugen hat und gerne mehr Übersicht hätte. Dann werden, genauso automatisch, eben zwei oder vielleicht gar drei Spalten angezeigt. Pro Zeile haben wir immer noch ungefähr so viele Buchstaben, der Text bleibt nach wie vor lesbar. Und auf Smartphones im Hochkant-Format? Kein Unterschied. Der Text wird automatisch in nur einer Spalte dargestellt.
Dieser Ansatz löst zwar nicht alle Probleme mit extrem stark divergierenden Geräten bei den Anwendern, aber es wird eine Menge Flexibilität erreicht, die der Darstellung der Seite zugute kommt. Die restlichen Maßnahmen (z.B. das Umverteilen der Seitengeometrie) kann dann von den bekannten Techniken des responsive Webdesigns leichter vorgenommen werden. Natürlich trifft das so in dieser Form eher auf textlastige Seiten zu. Aber man muss ja nicht die ganze Seite mit diesen Spalten ausrüsten. Auf dieser Seite ist z.B. der Navigationscontainer auch unabhängig davon. Auf den Bereich beschränkt, der hauptsächlich Text enthält, kann dieses Mehrspaltenlayout aber sehr nützlich sein.
Bei mir verwende ich folgende Angaben:
div.entry-content {
-moz-column-width: 26em;
-moz-column-gap: 1.6em;
-moz-column-rule: thin dotted black;
-webkit-column-width: 26em;
-webkit-column-gap: 1.6em;
-webkit-column-rule: thin dotted black;
-o-column-width: 26em;
-o-column-gap: 1.6em;
-o-column-rule: thin dotted black;
column-width: 26em;
column-gap: 1.6em;
column-rule: thin dotted black;
}
