Tatort war ein Palm Pre WebOS, Tatwerkzeug der eingebaute Browser auf WebKit-Basis.

Um das überhaupt nachzuvollziehen, habe ich den MobiOne Emulator für Palm Pre installiert. Das ging verdächtig leicht, und das Ergebnis half mir überhaupt nicht. Es war nämlich in Ordnung:

Dieser Emulator ist im Wesentlichen ein zurechtgestutztes Eclipse; seine Abhängigkeit vom Gastsystem erkennt man schon daran, daß er dessen Schriften benutzt. Unbrauchbar.

Dann habe ich das Palm webOS SDK installiert, das in einer virtuellen Maschine läuft – und das Problem ganz genau wiedergibt. Das scheint also ein recht realistisch arbeitendes Werkzeug zu sein. Etwas umständlich finde ich nur das englische Tastaturlayout, das ich nicht umstellen konnte.

Nach allerlei Tests habe ich endlich die Ursache gefunden: Ich hatte im Stylesheet eine Deklaration stehen, von der ich annahm, sie werde nur von Gecko interpretiert.

p,
address,
li
    {
        text-rendering:optimizeLegibility;
    }

Diese Eigenschaft stammt aus SVG, wie man leicht an der dämlichen Binnenmajuskel erkennt. Sie sollte Firefox dazu anregen, auch bei kleineren Schriftgraden als 20px das Kerning zu respektieren.
Was genau der Palm Browser hier versucht, vermag ich nicht zu sagen. Vielleicht hängt es mit der Schriftgröße zusammen, denn Überschriften, die mindestens 20px groß sind, werden noch gezeigt.

Ich habe die ganze Regel jetzt weggeworfen und einen Bugreport geschrieben.

Sicher ließe sich das auch hinter einem proprietären Selektor für Mozilla verstecken, aber davon will ich eigentlich weg. Und wenn ich damit leben kann, daß Mozilla-Nutzer noch keine abgerundeten Ecken sehen, dann darf ich genauso gut unterstellen, daß sie sich an schlampiges Kerning gewöhnt haben. Also nehmt es mir nicht übel, ja?

Ach ja, das aktuelle Ergebnis:

Da der Browser jetzt nur die Systemschriften des Palm OS verwendet, setzt er keine Kursivschnitte für serifenlose Schriften mehr um, und eine Monospace-Schrift findet oder nutzt er auch nicht. Das ist nicht schlimm, aber man kann es unter »Aha. Mist!« ablegen.

Wenn der Rhythmus stimmt.

Blocksatz in der YAML-Dokumentation

Damit meine ich nicht allein den Rhythmus der Sprache – bei dem Tempo spreche ich innerlich ohnehin nicht mehr mit – sondern den visuellen Eindruck. Viele kleine Absätze mit großem Abstand behindern meine Technik ebenso wie ein sehr hoher Zeilenabstand. Aber am schlimmsten finde ich schlechten Blocksatz.

Guter Blocksatz fällt nicht auf. Daran erkennt man gelungene Typographie: Der Abstand zwischen den einzelnen Zeichen (Kerning) paßt zu den Wortzwischenräumen und bleibt über viele Zeilen hinweg sehr konsistent. Ein geübter Setzer stimmt also Zeichen-, Wort- und Zeilenabstände aufeinander ab.
Im Ergebnis paßt der Grauwert am rechten Rand zu dem des übrigen Textes.

Schlechter Blocksatz kriegt nur den rechten Rand hin und zerstört den Rest. Zwischen den einzelnen Worten entstehen Abstände, die manchmal den größten Raum der Zeile beanspruchen und untereinander einen River of White Space bilden; Anfang und Ende eines Satzes muß der Leser suchen, weil das visuelle Signal (langer Abstand) dem Inhalt (der Satz geht weiter) widerspricht.

In der Ausgabe am Bildschirm haben wir als Autoren oft keinen oder wenig Einfluß auf die tatsächlich verwendete Schriftgröße. Eine zuverlässige automatische Silbentrennung können wir auch nicht benutzen, und ein Kerning, das für jede Zeile paßt, können wir uns ganz aus dem Kopf schlagen.

Guter Blocksatz ist in HTML und CSS nicht möglich. Selbst in E-Books wird er sehr, sehr schwer.

Aber ich kann doch … 

… eine feste Breite und Schriftgröße vorgeben, Umbrüche und Trennstriche manuell setzen und so einen akzeptablen Blocksatz erreichen?

Glücklicherweise nicht. Die Schriftgröße des Lesers ist unbekannt. Ebenso die verwendete Schrift. Wer HTML und CSS benutzt, der hat automatisch Koautoren; das ist eingebaut. Noch gibt es ein paar ›Designer‹, die sagen: »Selber schuld! Wer meine Vorgaben überschreibt, darf sich nicht beschweren.«
Als Physiker ignorierten die vermutlich auch die Schwerkraft, und als Lehrer die jugendliche Neugier.

… Javascript und Canvas benutzen?

Das scheitert an Browsern, die kein Canvas unterstützen, an abgeschaltetem Javascript und an der sehr schlechten Zugänglichkeit in <canvas> eingebetteter Texte.

Worauf ich hinaus will, ist aber keine typographische Frage, sondern: Für wen schreibe ich eigentlich? Für den willenlosen Leser ohne eigene Ansichten und Präferenzen? Oder für einen mündigen Leser, der beides eben hat und darum auch von meiner Ansicht überzeugt werden kann – oder ihr ein spannendes Argument entgegensetzt?
Für den ersten brauche ich gar nicht zu schreiben; das lohnt sich nicht. Und den zweiten sollte ich besser nie mit Blocksatz ärgern.

Lektüre

• Jukka "Yucca" Korpela: How do I justify text on both sides on Web pages?
• Ilene Strizver: Justified Type
• Typolexikon: Blocksatz
• Fritz Weisshart: Blocksatz, Silbentrennung und die Screen Reader (nachgetragen am 20. 10. 2010)

Überschriften sind der erste Teil des Textes, der gelesen wird. Manchmal auch der letzte. Deshalb wollen wir sie möglichst gut aussehen lassen.

Damit das letzte Wort einer Überschrift nicht in einer separaten Zeile verhungert, wenn jemand mit schmalem Browserfenster oder großer Schrift daherkommt, habe ich mir eine kleine Hilfsfunktion in meine Themes gebaut:

Update: Martin Gandrath hat meine Version erheblich verkürzt.

if ( ! function_exists('prevent_widows') )
{
    function prevent_widows($str)
    {
        $pos = strrpos($str, ' ');

        if ( $pos === false || strlen($str) - $pos > 11)
        { // Nothing to do.
            return $str;
        }
        /* U+00A0 NO-BREAK SPACE == C2 A0 in UTF-8
         * @see http://www.fileformat.info/info/unicode/char/00a0/index.htm
         */
        return substr_replace($str, "\xC2\xA0", $pos, 1);
    }
}
add_filter('the_title', 'prevent_widows');

Wenn also das letzte Wort kürzer als 11 Zeichen ist, dann wird es mit einem geschützten Leerzeichen an das vorletzte gebunden. Hier schlägt es demnach zu, bei den Grundlagen der Zeichenkodierung aber nicht.

In Ermangelung eines besseren Ausdrucks nenne ich solche Worte hier Widow (zu Deutsch: Witwe, früher Hurenkind). Da kein Seitenumbruch in der Überschrift entsteht, stimmt das eigentlich nicht. Egal.

Ich hätte das vermutlich nie gebloggt, wenn nicht Chris Coyier neulich danach gefragt hätte. Offenbar ist diese Lösung doch nicht so selbstverständlich, wie ich dachte.

Shaun Inman hat ein Plugin namens »Widon’t« geschrieben, das ungefähr dasselbe tut – mit ein paar Unterschieden:

• Es arbeitet mit einem regulären Ausdruck.
• Es prüft nicht die Länge des letzten Wortes – was im Englischen ja meistens kein Problem ist.
• Es erfaßt auch andere HTML-Elemente, wenn man die entsprechende Option einstellt.
• Es geht ein bißchen sorglos mit dem POST-Request für die Optionen um. Nichts Dramatisches, aber es gibt bessere Wege …
  Ich habe Shaun darüber informiert; dieses Problem wird also vermutlich in der nächsten Version behoben sein.

Verwandte Artikel

• Warum man Inhalt und Layout nicht trennen kann
• Den Titel voran!
• PHP-Funktion Genitiv

1. Scott Boms: Burnout.
   

   Web professionals are often expected to be “always on”—always working, absorbing information, and honing new skills. Unless our work and personal lives are carefully balanced, however, the physical and mental effects of an "always on" life can be debilitating.

   Boms spricht hier sehr offen über ein Problem, mit dem vermutlich viele Webworker zu kämpfen haben: Hinter all der guten Laune, dem steten Lernen, Basteln und Kritisieren, das man auf Twitter und den Fachblogs lesen kann, steht oft ein ungeheurer Druck, den niemand zeigen oder überhaupt wahrnehmen will.

2. Eine Monitortapete mit typographischen Fachbegriffen hat Sigurdur Armannsson entworfen. Wer gibt uns das deutschsprachige Pendant?
3. Jeff Starr: The 5-Minute CSS Mobile Makeover.
   Das Understatement des Monats. Lektüre satt.
   Ebenfalls dort: Htaccess Password-Protection Tricks.
4. @font-face-kits.
   Das nenne ich mal praktisch: Knapp 200 Schriften als fertige Pakete inklusive EOT-Dateien und Beispielstylesheets zum Downlad.
5. Hallvord R. M. Steen: Most expensive javascript ever?
   Schlechte Scripte entpuppen sich ja oft als Verkaufsbremse. Aber so schlimm darf es nie werden.
6. BDG (Bund Deutscher Grafik-Designer e.V.): Lebensumstände selbstständiger Designer nach dem Berufsstart (kein Link mehr, Amateure).
   Die Ergebnisse einer Umfrage vom April dieses Jahres. Für den Nachwuchs vielleicht eine Entscheidungshilfe und sicher ein wichtiger Baustein des Businessplans.
   Ein paar interessante Zahlen:
   • 16,8% der Designer sind Quereinsteiger.
   • 64,8% arbeiten ökonomisch selbständig, davon 60,7 % ohne Partner.
   • 8% haben keinen Computer. Faxen die ihre Entwürfe?
   • 35% kaufen keine Schriften, waraus der Autor flott schlußfolgert, daß die vermutlich klauen.
   • Wer nach Stunden abrechnet, liegt meistens zwischen 30—70 €. Wie man mit 30 € pro Stunde noch schwareze Zahlen schreiben kann, sei mal dahingestellt …
   • 68,9% generieren neue Aufträge, indem sie von Bestandskunden empfohlen werden. Deshalb kostet das erste halbe Jahr auch so viel Kraft. Wer das durchhält und gute Arbeit abliefert, der braucht – so meine Erfahrung – kaum noch Akquise zu betreiben.
   • Die meisten Rechnungen werden binnen vier Wochen beglichen. Dennoch muß man immer einkalkulieren, daß ein Kunde gar nicht bezahlt. Das ist mir am Anfang passiert – sehr unangenehm. Nach der Vorkasse wurde offenbar nicht gefragt. Die spielt aber eine wichtige Rolle; nicht nur ökonomisch, sondern auch für die Motivation …
   • 20% können nicht allein von ihrem Einkommen leben. Das ist eine Menge.
7. Und noch ein Blog will ich empfehlen: Heiko Kunerts »Blind-PR«.
   Heiko ist vollblind und schreibt mit viel Humor darüber. Besonders angesprochen haben mich die Geschichte über die aufdringlichen positiven Vorurteile eines … Tischwegweisers und Ute Gerhardts Gastbeitrag: »Alltag mit blinden Eltern«. Stöbert mal. Das lohnt sich.

• Web font embedding, points missing
  Die meisten Schriften, so der ungenannte Autor (David John Earls oder Yves Peters), seien gar nicht für den Bildschirm geeignet, die Debatte um ihre »Weblizenz« daher Unsinn.
  Das ist richtig. Und falsch.
  Erstens gibt es ja auch Druckstylesheets, auch wenn die Autoren dieser Seite davon offensichtlich noch nichts gehört haben. Zweitens reden wir auch über künftige Schriften, und drittens eignen sich einige kommerzielle Schriften schon jetzt für die Bildschirmausgabe – und sei es nur für Überschriften.
  Manche Fragen kann man nicht beantworten, indem man sie für irrelevant erklärt. [Typographie]
• Das hat sogar das W3C eingesehen und eine Fonts Working Group angeregt (Chris Lilleys E-Mail dazu), die vor allem die Formatfrage klären soll. Viel Erfolg! [Typographie]
• Hilbrand Edskes: IE8 overflow and expanding box bugs
  Fünf wirklich fiese Bugs des Internet Explorers 8 mit der Eigenschaft overflow. [CSS]
• Und da ich gerade den Link setze, fällt mir ein: Es gibt eine neue Version für CSS 2.1, und sie steht jetzt unter der URL der alten Version CSS 2.0: www.w3.org/TR/CSS2/. Und unter der URL www.w3.org/TR/CSS21/. Wieso scheitert eigentlich jede Woche jemand am Konzept der kanonischen URLs? Ist das so schwer? Oder bin ich bloß altmodisch? [CSS]
• Der VfB Stuttgart bietet echten Fans einen eigenen Browser an. Keine Angst, es ist ein angepaßter Opera. [Browser]
• designerdaily: Hitler freaks out over Comic Sans MS

  Auf Youtube hat sich ein richtiger Sport daraus entwickelt, diese Szene mit Untertiteln zu versehen. Diese aber empfinde ich als die gelungenste Variante. [Typographie]

• Mathias Schäfer, den wir auch unter dem nom de guerre »molily« kennen, hat einen Artikel zur Qualitätssicherung mit XHTML und HTML geschrieben. Die Details für seine HTML-Lösung möchte ich wirklich gerne sehen …

  Auch hier will ich wieder einmal das ganze Blog empfehlen: Mathias schreibt seit Jahren in (viel zu) großen Abständen lesenswerte Artikel. Früher im SELFHTML-Weblog, jetzt im eigenen. Stöbern lohnt sich. Aber seid so freundlich, und setzt den Newsreader auf eine Abfrage pro Tag. [Markup]

Das war’s für heute; ich bin gerade mit Arbeit vollgepackt.

Grundlagen

Ich arbeite mit der Schriftgröße meiner Leser. Die Maße aller Boxen beziehe ich auf diese Größe, damit nirgendwo Text ausläuft.

Ich unterstelle keine »Standardschriftgröße«, weil ich Ockhams Rasiermesser für eines der wichtigsten Werkzeuge jedes Gestalters halte: Die Annahme, meine Leser hätten diese oder jene Schriftgröße, ist überflüssig und fast nie verifizierbar. Selbst Studien, die allein die Größe messen, sagen nichts über Mindestschriftgrößen oder ob der Leser genau 16px mag.

Zwar haben die meisten Browser ab Werk eine Größe von 16 Pixeln eingestellt, aber ob der Leser es dabei belassen hat oder nicht, kann niemand sagen. Im Internet Explorer sind es übrigens 12 Punkt, die bei der Systemeinstellung »Große Schriften« erheblich größer ausfallen als 16 Pixel.

Vorteile

Nicht nur meine Leser profitieren davon, sondern auch ich: Wenn ich in meinem Layout auf leserfremde Größen setzte, müßte ich testen, was passiert, wenn meine Besucher diese Größenangaben ignorieren (das bietet heute jeder Browser an), und wie mein Entwurf mit Mindestschriftgrößen harmoniert. Das erspare ich mir; so habe ich mehr Zeit für richtiges Design.

Viele Entwickler vergessen diese Tests; sie »optimieren« ein Layout im Grunde bloß für die eigenen Verhältnisse und vielleicht für die ihrer Kunden. Schade. Im Netz sind so viel mehr Menschen unterwegs.

CSS

Im Stylesheet setze ich die Schriftgröße (font-size) für body auf 100.01%. Wenn ich die Angabe komplett weglasse oder als 1em angebe, skaliert der Internet Explorer 6 sehr drastisch. Bei genau 100% ziehen ältere Operaversionen (5 & 6) einen Pixel ab, bei 100.1% verkalkuliert sich Safari 1.x bei Breitenangaben in em. All dies sind eigentlich schon veraltete Probleme. Es kostet aber nichts, wenn ich sie immer noch berücksichtige.

Denn darum geht es ja (nicht nur) beim Webdesign: Wer ernst genommen werden will, der muß auch seine Leser ernst nehmen.

Lektüre

• Mathias Schäfer: (Keine Antwort auf) Die Frage nach der richtigen Schriftgröße.
  Differenzierte Betrachtung der vielen Faktoren für die Lesbarkeit.
• Oliver Reichenstein: The 100% Easy-2-Read Standard.
  Pointierte und illustrierte Aufforderung, lesbare Webseiten zu gestalten.
• In diesem Blog:
  • Mythos font-size: 62.5%: Was geschieht, wenn man die Mindestschriftgröße vergißt.
  • Zu groß: Größer ist nicht automatisch besser. Ein extremes Fallbeispiel.
  • Zu klein: »font-family: monospace« in Safari: Wenn 100% nicht 100% sind.