Typografie - vertikaler Rhythmus

[Gunther]

Hallo werte Selfgemeinde!

Da ich mich nun schon mehrere Tage intensiv mit dem Thema beschäftigt habe, und trotzdem noch zu keinem "zufriedenstellenden" Resultat gekommen bin, möchte ich doch mal bitte eure Meinung hören.

Erstaunlicherweise sehen (fast) alle Webseiten, die sich mit dem Thema beschäftigen, optisch nicht gerade "ansprechend" aus, was das Thema anbelangt.

Was meinen bisherigen Eindruck, dass man gar nicht alle theoretischen Vorgaben in die Praxis umsetzen kann, nur verstärkt hat.

Aber zur Sache:

Gehen wir davon aus, dass normaler Fließtext eine Schriftgröße von 1em hat, und die line-height 1.5 beträgt (was die line-height anbelangt scheint das auch der weitverbreitste Wert zu sein).

Ferner gehen wir davon aus, dass der Abstand zwischen zwei Absätzen eine (Leer)Zeile beträgt.

p {  
   margin: 1.5em 0;  
}

Für Überschriften sollen folgende Schriftgrößen gelten:

h1 {  
   font-size: 2em;  
}  
h2 {  
   font-size: 1.5em;  
}  
h3 {  
   font-size: 1.17em;  
}  
h4 {  
   font-size: 1em;  
}  
h5 {  
   font-size: 0.83em;  
}  
h6 {  
   font-size: 0.67em;  
}  

Nun stehen uns die Eigenschaften

- line-height
 - margin (top + bottom)
 - padding (top + bottom)

zur Verfügung, um unseren vertikalen Rhythmus zu etablieren.

Vor jeder Überschrift soll mindestens eine Leerzeile Platz sein (außer es handelt sich um die erste Überschrift eines "Blocks").

Das wird ja i.d.R. schon durch unsere Regel für 'p' sichergestellt, da keine zwei Überschriften, ohne unterbrechenden Text, aufeinanderfolgen (sollten).

Die erste "Schwierigkeit" besteht (für mich) schon darin, dass man AFAIS davon ausgehen muss, dass eine Überschrift prinzipiell nicht umgebrochen wird, oder man muss mit "unbrauchbaren" line-height Werten arbeiten.

Denn "optisch" ist speziell für höherrangige Überschriften eine kleinere line-height als die unsere Basis-Line-Height angebracht. Auch sollte der Abstand vor einer Überschrift größer sein, als der nachfolgende.

Eine weitere "Problematik" besteht auch darin, dass egal welche Basis-/ Ausgangswerte man wählt, man immer auch sehr "krumme" Werte (häufig auch Werte mit Periode) erhält, was zu Abweichungen durch Rundungen führt, die sich speziell auf Seiten mit mehr "Text" dann auch optisch bemerkbar machen.

Bis hierhin mag man das, mit gewissen "Einschränkungen", ja noch einigermaßen hinkriegen ...!
Aber wenn ich jetzt auch noch ein mehrspaltiges Layout (bspw. 3 Spalten - 2 Sidebars und 1 Hauptspalte) habe, und den vertikalen Rhythmus dieser Spalten "harmonisieren" (angleichen) möchte, dann ist "der Ofen völlig aus" ...!

Denn im Normalfall sollen die Sidebars eine kleinere Basis-Schriftgröße haben, und somit auch eine geringere line-height. Dürfen aber auch durchaus Überschriften aller Ränge enthalten etc.

Ich habe bisher leider noch keinen geeigneten Weg gefunden, alle diese "Anforderungen" zufriedenstellend unter einen Hut zu kriegen.

Von daher die Frage, wie macht ihr das?

Auch über Links zu Seiten, wo das dementsprechend "gut" umgesetzt ist, würde ich mich freuen (bitte nicht einfach irgendwelche Seiten aus entsprechenden Google Treffern verlinken - die habe ich mit 99%iger Wahrscheinlichkeit auch schon gesehen).

Mir ist durchaus bewusst, dass das wieder so ein Thema ist, wo es nicht "die eine perfekte Lösung" gibt, und man (vermutlich) im Endeffekt irgendeinen Tod sterben muss ...!

Deshalb erwarte ich auch eher eine Diskussion zum Thema, denn "fertige Lösungen".

In diesem Sinne,
Gruß Gunther

[JürgenB]

Hallo Gunther,

nur zwei Anmerkungen:

Ich würde eine Überschrift nie kleiner als den Text machen.

Warum sollen zwei Überschriften (unterschiedlichen Grades) nicht direkt aufeinander folgen?

Gruß, Jürgen

[Gunther]

Hallo Jürgen,

nur zwei Anmerkungen:

Ich würde eine Überschrift nie kleiner als den Text machen.

Ja, kann man sicherlich so halten, muss man aber nicht.
Die beispielhaft angenommenen Werte entsprechen übrigens dem Browser Stylesheet von Chrome.

Warum sollen zwei Überschriften (unterschiedlichen Grades) nicht direkt aufeinander folgen?

Weil es sich bei dem zweiten Element dann um eine Sub-Heading handeln würde, und diese laut HTML5 Spec nicht mit einem Hx Element ausgezeichnet werden.

Das hat auch etwas mit der Outline von HTML5 zu tun.

Gruß Gunther

[JürgenB]

Hallo Gunther,

Warum sollen zwei Überschriften (unterschiedlichen Grades) nicht direkt aufeinander folgen?

Weil es sich bei dem zweiten Element dann um eine Sub-Heading handeln würde, und diese laut HTML5 Spec nicht mit einem Hx Element ausgezeichnet werden.

und wie würde dann

Kapitel 1
  Kapitel 1.1
    Kapitel 1.1.1
      Kapitel 1.1.1.1
        Text zu 1.1.1.1
      Kapitel 1.1.1.1
        Text zu 1.1.1.2
   ...

ausgezeichnet? Muss jedes Unterkapitel in ein <section> oder kann es das nur?

Gruß, Jürgen

[Gunther]

Hallo Jürgen!

Warum sollen zwei Überschriften (unterschiedlichen Grades) nicht direkt aufeinander folgen?

Weil es sich bei dem zweiten Element dann um eine Sub-Heading handeln würde, und diese laut HTML5 Spec nicht mit einem Hx Element ausgezeichnet werden.

und wie würde dann

Kapitel 1
  Kapitel 1.1
    Kapitel 1.1.1
      Kapitel 1.1.1.1
        Text zu 1.1.1.1
      Kapitel 1.1.1.1
        Text zu 1.1.1.2
   ...

ausgezeichnet? Muss jedes Unterkapitel in ein <section> oder kann es das nur?

Der Punkt ist doch, dass normalerweise bereits nach "Kapitel 1" erstmal Text folgt, bevor ein Unterkapitel anfängt. Insofern erübrigt sich imho eine Antwort, oder bereits das Nachdenken über eine solche, da sich die Frage eigentlich nicht stellt. ;-)

Aber so ad hoc würde ich eher dazu tendieren, dass mit verschachtelten Sections zu machen.
Allein schon weil man Section ja durchaus auch mit Kapitel übersetzen kann, jedes Kapitel also in sich eine abgeschlossene Section darstellt.

Das ist aber ein komplett anderes Thema ...! ;-)

Gruß Gunther

[JürgenB]

Hallo Gunther,

Der Punkt ist doch, dass normalerweise bereits nach "Kapitel 1" erstmal Text folgt, bevor ein Unterkapitel anfängt. Insofern erübrigt sich imho eine Antwort, oder bereits das Nachdenken über eine solche, da sich die Frage eigentlich nicht stellt. ;-)

Nein. Ich habe gerade aus meinem Bücherregal drei Bücher genommen (also eine repräsentative Auswahl), in allen gab es Kapitel mit Text zwischen hx und hx+1 und (!) ohne Text dazwischen.

Hier ein Online-Beispiel http://www.wwu.de/Physik.AP/Purwins/DE/ElNw-de.html in "uraltem" Markup.

Zum Rest hat sich Gunnar schon geäußert.

Gruß, Jürgen

[Gunther]

Hallo Jürgen!

Der Punkt ist doch, dass normalerweise bereits nach "Kapitel 1" erstmal Text folgt, bevor ein Unterkapitel anfängt. Insofern erübrigt sich imho eine Antwort, oder bereits das Nachdenken über eine solche, da sich die Frage eigentlich nicht stellt. ;-)

Nein. Ich habe gerade aus meinem Bücherregal drei Bücher genommen (also eine repräsentative Auswahl), in allen gab es Kapitel mit Text zwischen hx und hx+1 und (!) ohne Text dazwischen.

Nicht alles, was im Print Design erlaubt und gemacht wird, kannst du auch 1:1 aufs Webdesign übertragen ...! ;-)

Aber es ist natürlich durchaus valide (und somit erlaubt), dass mehrere Hx Elemente unmittelbar aufeinanderfolgen.

Mit HTML5 und dem (neuen) Outline Algorhythmus gibt es zwei verschiedene Arten, wie die Outline "gebildet" wird, nämlich einmal explizit, und einmal implizit.

Letzteres sehe ich (persönlich) eher als ein Zugeständnis an die Abwärtskompatibilität an, genauso wie der Verzicht auf ein einziges "generisches" H-Element.

Daraus ergeben sich für mich quasi 2 unterschiedliche "Schreib-Stile".

Den einen, unter Verwendung aller Hx Elemente, würde ich jetzt mal als "Old School" (eben im HTML < 5 Stil) bezeichnen.

Den anderen als (zumindest eher) "HTML5 Style", sprich anstatt auf implizite Sektionierung rein auf die explizite Form zu setzen, und dann jeweils immer ein H2 Element (H1 soll aktuell, aufgrund mangelnder Fähigkeiten von Screenreadern, auf jeder Seite nur einmal vorkommen/ verwendet werden) als section heading zu verwenden (quasi als "generisches" H-Element), und es somit dem jeweiligen UA zu überlassen, den jeweiligen "Rang" der Überschrift zu ermitteln.

Wir hatten hier im Forum diesbezüglich auch schon mehrere Diskussionen.

Welche Variante man nun persönlich bevorzugt, bleibt natürlich jedem selbst überlassen.

Da ich, wie bereits erwähnt, Anhänger der Variante mit dem "generischen" H(2)-Element bin, stellt sich für mich die Situation, dass zwei H-Elemente unmittelbar aufeinanderfolgen eigentlich nicht.

Aber selbst wenn, ist das bezogen auf das eigentliche Thema des Threads ja auch kein Problem, da ich bereits im Ausgangsposting geschrieben hatte, dass ich jedem (H-)Element auch ein 'margin-top' mitgebe, was entsprechend der (relativen) Schriftgröße genau eine Zeilenhöhe groß ist.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Weil es sich bei dem zweiten Element dann um eine Sub-Heading handeln würde, und diese laut HTML5 Spec nicht mit einem Hx Element ausgezeichnet werden.

Du meinst „h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines“? [HTML5]

Du musst den Satz aber auch zuende lesen: „unless intended to be the heading for a new section or subsection.“

<h1>Pu der Bär</h1>  
<h2>Widmung</h2>  
<p>…  
  
<h2>Rückstellung</h2>  
<p>…

ist durchaus richtig, denn die h2 sind Überschriften eines neuen Abschnitts. Das könnte man natürlich auch als

<h1>Pu der Bär</h1>  
<section>  
  <h2>Widmung</h2>  
  <p>…  
</section>  
<section>  
  <h2>Rückstellung</h2>  
  <p>…  
</section>

auszeichnen, muss man aber nicht.

Hingegen wäre

<h2>Achtes Kapitel<h2>  
<h3>In welchem Christopher Robin eine Expotition zum Nordpohl leitet</h3>

falsch. Das wäre die Art von Untertitel, die nicht mit h#-Elementen ausgezeichnet werden sollen, sondern z.B. als

<header>  
  <h2>Achtes Kapitel<h2>  
  <p>In welchem Christopher Robin eine Expotition zum Nordpohl leitet</p>  
</header>

Das hat auch etwas mit der Outline von HTML5 zu tun.

Eben. „Widmung“ gehört in die Outline.

„In welchem Christopher Robin eine Expotition zum Nordpohl leitet“ hingegen nicht – jedenfalls nicht als Unterpunkt zu „Achtes Kapitel“.

Wenn doch, dann zusammen mit diesem. Also ausgezeichnet als

<h2>  
  <span class="chapter-number">Achtes Kapitel<span>  
  <span class="subtitle">In welchem Christopher Robin eine Expotition zum Nordpohl leitet</span>  
</h2>

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Ja, du hast das natürlich wieder in Perfektion ausgeführt ...!

Weil es sich bei dem zweiten Element dann um eine Sub-Heading handeln würde, und diese laut HTML5 Spec nicht mit einem Hx Element ausgezeichnet werden.

Du meinst „h1–h6 elements must not be used to markup subheadings, subtitles, alternative titles and taglines“? [HTML5]

Du musst den Satz aber auch zuende lesen: „unless intended to be the heading for a new section or subsection.“

<h1>Pu der Bär</h1>

<h2>Widmung</h2>
<p>…

<h2>Rückstellung</h2>
<p>…

>   
> ist durchaus richtig, denn die h2 sind Überschriften eines neuen Abschnitts. Das könnte man natürlich auch als  
>   
> ~~~html

<h1>Pu der Bär</h1>  

> <section>  
>   <h2>Widmung</h2>  
>   <p>…  
> </section>  
> <section>  
>   <h2>Rückstellung</h2>  
>   <p>…  
> </section>

auszeichnen, muss man aber nicht.

Alles richtig ..., aber es ging (mir) primär darum, dass zwischen zwei Überschriften "normalerweise" auch noch Text liegt.

Und ich finde es immer äußerst "erquickend", wenn die Code Beispiele in der W3C Spec in deren Validator zumindest eine Warning erzeugt ...! :-P

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Alles richtig ..., aber es ging (mir) primär darum, dass zwischen zwei Überschriften "normalerweise" auch noch Text liegt.

Normalität liegt im Auge des Betrachters.

Ich finde es völlig normal (und auch häufig anzutreffen), wenn die erste Unterüberschrift gleich auf die übergeordnete Überschrift folgt.

Und ich finde es immer äußerst "erquickend", wenn die Code Beispiele in der W3C Spec in deren Validator zumindest eine Warning erzeugt ...! :-P

Wovon sprichst du?

Qapla'

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Aber wenn ich jetzt auch noch ein mehrspaltiges Layout (bspw. 3 Spalten - 2 Sidebars und 1 Hauptspalte) habe, und den vertikalen Rhythmus dieser Spalten "harmonisieren" (angleichen) möchte, dann ist "der Ofen völlig aus" ...!

Denn im Normalfall sollen die Sidebars eine kleinere Basis-Schriftgröße haben, und somit auch eine geringere line-height.

Für den vertikalen Rhuthmus ist es auch möglich, dass Zeilenhöhen von Hauptteil und Seitenspalte in ganzzahligem Verhältnis stehen (kleine ganze Zahlen). Bspw. 3:2, jede 2. Zeile des Hauptteils steht mit jeder 3. der Seitenspalte auf derselben Grundlinie.

Hauptteil:    Schriftgröße   1em (1rem),   Zeilenhöhe: 1.5 (1.5rem)
Seitenspalte: Schriftgröße 0.8em (0.8rem), Zeilenhöhe: 1.25 (1rem)

Dürfen aber auch durchaus Überschriften aller Ränge enthalten etc.

Jetzt übertreibst du’s aber. ;-)

Aber es sollte möglich sein, mit die Überschriften in der Seitenspalte entwerder ins 1rem-Raster oder ins 1.5rem-Raster zu bekommen.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Aber wenn ich jetzt auch noch ein mehrspaltiges Layout (bspw. 3 Spalten - 2 Sidebars und 1 Hauptspalte) habe, und den vertikalen Rhythmus dieser Spalten "harmonisieren" (angleichen) möchte, dann ist "der Ofen völlig aus" ...!

Denn im Normalfall sollen die Sidebars eine kleinere Basis-Schriftgröße haben, und somit auch eine geringere line-height.

Das habe ich misverständlich formuliert.
Mit "geringerer line-height" war in diesem Fall der absolute/ berechnete Wert der line-height gemeint, und nicht der Faktor!

Für den vertikalen Rhuthmus ist es auch möglich, dass Zeilenhöhen von Hauptteil und Seitenspalte in ganzzahligem Verhältnis stehen (kleine ganze Zahlen). Bspw. 3:2, jede 2. Zeile des Hauptteils steht mit jeder 3. der Seitenspalte auf derselben Grundlinie.

Hauptteil:    Schriftgröße   1em (1rem),   Zeilenhöhe: 1.5 (1.5rem)
Seitenspalte: Schriftgröße 0.8em (0.8rem), Zeilenhöhe: 1.25 (1rem)

Ja, schon klar. Anders wäre ja vermutlich auch immer die Zeilenhöhe für die Seitenspalten "zu groß".

Ganz konkret habe ich u.a. den Fall, dass meine line-height von 1.5 bei 16px Basis-Schriftgröße genau 33px entspricht. Somit meine Schriftgröße für FLießtext 22px.

Die Schriftgröße für FLießtext in den Seitenspalten soll 18px groß sein (natürlich alles in r/em - nur der Einfachheit halber hier als Pixelwerte).

Kleine Veränderungen (1/10) des line-height Faktors haben optisch aber schon große Auswirkungen.

Rein optisch betrachtet ist bei obigem Szenario ein line-height Faktor von 1.5 - 1.4 "passend".

Das bedeutet aber, wenn bspw. die line-height für Haupt- und Seitenspalten gleich 1.5 ist, dass sich für die Seitenspalten ein "Grundraster" von 27px ergibt und für die Hauptspalte von 33px.

Das KGV von 33 und 27 ist 297.
Von daher läge also erst jede 11. Zeile (297 / 27 = 11) der Seitenspalte wieder auf derselben Grundlinie.

Das ist ein deutlich zu hoher Wert, um den "optischen Gesamteindruck" zu wahren.

Es gibt aber in dem Bereich der erwünschten line-height (1,4 - 1,5) keinen Wert, der zu einem "günstigeren" Ergebnis führen würde.

Außerdem empfinde ich es zumindest als "harmonischer", wenn die line-height durchgehend denselben Faktor (1,5) hat.

Dürfen aber auch durchaus Überschriften aller Ränge enthalten etc.

Jetzt übertreibst du’s aber. ;-)

Ja, OK. ;-)

Aber es sollte möglich sein, mit die Überschriften in der Seitenspalte entwerder ins 1rem-Raster oder ins 1.5rem-Raster zu bekommen.

Ja, wäre wünschenswert.

Irgendeinen Tipp bezüglich der Mehrzeiligkeit von Überschriften?
Oder muss man das dann als die berühmte Ausnahme an-/ hinnehmen?

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Ganz konkret habe ich u.a. den Fall, dass meine line-height von 1.5 bei 16px Basis-Schriftgröße genau 33px entspricht.

Sicher kein besonders günstiger Wert, um andere Zeilenhöhen damit in ein ganzzahliges Verhältnis zu bringen.

Obwohl, 22px für die Seitenspalte …

Die Schriftgröße für FLießtext in den Seitenspalten soll 18px groß sein

Für 22px Zeilenhöhe ist 18px wohl etwas groß. Vielleicht kannst du auf 17px oder 16px runtergehen?

Das KGV von 33 und 27 ist 297.
Von daher läge also erst jede 11. Zeile (297 / 27 = 11) der Seitenspalte wieder auf derselben Grundlinie.

Das ist ein deutlich zu hoher Wert, um den "optischen Gesamteindruck" zu wahren.

Ja, deshalb sprach ich auch von „kleinen ganzen Zahlen“. Wie in der Musik: 1:2 Oktave, 2:3 Quinte, 3:4 Quarte.

Außerdem empfinde ich es zumindest als "harmonischer", wenn die line-height durchgehend denselben Faktor (1,5) hat.

Dass die Zeilenhöhe durchaus von der Satzbreite abhängen kann (sollte), hatten wir doch schon. In der Seitenspalte wäre ein kleinerer Wert als 1.5 durchaus angebracht.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Ganz konkret habe ich u.a. den Fall, dass meine line-height von 1.5 bei 16px Basis-Schriftgröße genau 33px entspricht.

Sicher kein besonders günstiger Wert, um andere Zeilenhöhen damit in ein ganzzahliges Verhältnis zu bringen.

Ja, das ist mir auch schon aufgefallen ...! :-P

Obwohl, 22px für die Seitenspalte …

Was für "22px für die Seitenspalte"!?

22px ist die Fließtextgröße der Hauptspalte.
Und die der Seitenspalten soll dann 18px betragen - s.u.

Die Schriftgröße für FLießtext in den Seitenspalten soll 18px groß sein

Für 22px Zeilenhöhe ist 18px wohl etwas groß. Vielleicht kannst du auf 17px oder 16px runtergehen?

Klar könnte man theoretisch immer weiter nach unten gehen mit der Schriftgröße, aber das ist ja nicht Sinn der Sache.

Sondern die Hauptspalte soll eine der Viewportbreite "angemessene" (gut lesbare) Schriftgröße haben, und die der Seitenspalten soll einerseits zwar "deutlich/ erkennbar" kleiner sein, andererseits aber auch noch gut lesbar bleiben.

Das KGV von 33 und 27 ist 297.
Von daher läge also erst jede 11. Zeile (297 / 27 = 11) der Seitenspalte wieder auf derselben Grundlinie.

Das ist ein deutlich zu hoher Wert, um den "optischen Gesamteindruck" zu wahren.

Ja, deshalb sprach ich auch von „kleinen ganzen Zahlen“. Wie in der Musik: 1:2 Oktave, 2:3 Quinte, 3:4 Quarte.

Versteh' ich prinzipiell schon ...,
aber 1:2 würde absolut gesehen ja heißen, Seitenspalte halbe line-height der Hauptspalte. Das wäre natürlich deutlich zu klein.

Nehmen wir mal 3:4
3 * 33 = 99
99 / 4 ~ 25

Ergäbe also einen absoluten Wert von 25px für die line-height.
Damit könnte man leben ..., "doll" aussehen tut das aber nicht! ;-)

Außerdem empfinde ich es zumindest als "harmonischer", wenn die line-height durchgehend denselben Faktor (1,5) hat.

Dass die Zeilenhöhe durchaus von der Satzbreite abhängen kann (sollte), hatten wir doch schon. In der Seitenspalte wäre ein kleinerer Wert als 1.5 durchaus angebracht.

Ja, hatten wir schon ...!
Nach welchem Verhältnis machst du das denn?

Ich persönlich empfinde aber u.a. eine größere Zeilenhöhe als nicht so negativ, wie eine "zu kleine".

In dem konkreten Beispiel hier (mit den absoluten Pixelwerten) empfinde ich es ab einer Zeilenhöhe < 1.3 als "zu eng".

Die Seitenspalten sind übrigens 20em (von der Body Schriftgröße - hier 22px), und die Hauptspalte 40em breit ()evt. noch abzüglich ~ 1em padding links und rechts).

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Was für "22px für die Seitenspalte"!?

22px Zeilenhöhe für die Seitenspalte. Damit sie in „gutem“ Verhältnis zur Zeilenhöhe in der Hauptspalte steht.

Klar könnte man theoretisch immer weiter nach unten gehen mit der Schriftgröße, aber das ist ja nicht Sinn der Sache.

[ ] frei wählbare Schritgrößen in Haupt- und Seitenspalte
[ ] Zeilenhöhen im Verhältnis kleiner ganzer Zahlen
[ ] Zeilenhöhen 1.5faches der jeweiligen Schriftgröße

Wähle 2 davon, nicht 3.

Ja, hatten wir schon ...!
Nach welchem Verhältnis machst du das denn?

Augenmaß; hatten wir schon. ;-b

In dem konkreten Beispiel hier (mit den absoluten Pixelwerten) empfinde ich es ab einer Zeilenhöhe < 1.3 als "zu eng".

Hängt von der Satzbreite ab …

Die Seitenspalten sind übrigens 20em … breit

Bei 20em könnte 1.3 doch passen.

Ich könnte mir auch vorstellen, dass eine Seitenspalte mit zu großem Zeilenabstand mehr vom Hauptinhalt ablenkt.

Qapla'

[Linuchs]

Eine weitere "Problematik" besteht auch darin, dass egal welche Basis-/ Ausgangswerte man wählt, man immer auch sehr "krumme" Werte (häufig auch Werte mit Periode) erhält, was zu Abweichungen durch Rundungen führt, die sich speziell auf Seiten mit mehr "Text" dann auch optisch bemerkbar machen.

Du scheinst irgendwas zu berechnen. Was? Und zu welchem Zweck?

Linuchs

[Gunther]

Hi Linuchs!

Eine weitere "Problematik" besteht auch darin, dass egal welche Basis-/ Ausgangswerte man wählt, man immer auch sehr "krumme" Werte (häufig auch Werte mit Periode) erhält, was zu Abweichungen durch Rundungen führt, die sich speziell auf Seiten mit mehr "Text" dann auch optisch bemerkbar machen.

Du scheinst irgendwas zu berechnen.

Was?

Zum Beispiel die top und bottom margins und paddings ...

Und zu welchem Zweck?

Um einen vertikalen Rhythmus zu erhalten!

Basierend auf den in meinem Ausgangsposting vorausgesetzen Werten, "brechnet" sich bspw. der Wert für margin-top eines Überschriftenelemnts als:

margin-top: 1.5 (line-height) / Schriftgröße des Hx Elements [em]

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Hab den Artikel Using Sass to Build a Custom Type Scale with Vertical Rhythm selbst noch nicht gelesen, aber vielleicht ist er was für dich.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Hab den Artikel Using Sass to Build a Custom Type Scale with Vertical Rhythm selbst noch nicht gelesen, aber vielleicht ist er was für dich.

Danke für den Tipp ...! :-)

Aber ..., nach dem Durchlesen und Begutachtung des Ergebnisses, finde ich die Variante "nicht gut".
Er steuert den vertikalen Rhythmus einzig über die Zeilenhöhe, die zudem teilweise bei der Art der Berechnung "unbrauchbare" Werte (line-height ~ 1) liefert.

Außerdem berücksichtigt seine "Formel" die Zeilenlänge nicht.

Ich bin inzwischen zu dem "Ergebnis" (oder der Meinung) gekommen, dass man den vertikalen Rhythmus nur unter der Einschränkung einzeiliger Überschriften erstmal per CSS etablieren kann.
Für "mehrzeilige" Überschriften kann man dann ggf. per JS nachhelfen.

Ferner erscheint mir, bis jetzt zumindest, eine Variante mit gleichbleibendem Line-Height-Faktor am geeignetsten.

Und dann, je nach Schriftgröße, ein (ganzzahliges) Vielfaches der Basis-Line-Height (Grundraster).

Margin-top so wählen, dass er immer dem absoluten Wert der Line-Height entspricht, und ansonsten die Überschrift per padding-top + bottom mittig ausrichten.

Als Formel für die Berechnung der Basis-Line-Height "eignet" sich imho diese hier:

  
@mixin lineHeight($font-value, $line-width-value) {  
	$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 * (1 - $line-width-value/(pow($font-value*1.61803398875, 2)));  
	$lineHeightValue : round($font-value * $lineHeightRatio);  
	$lineHeightRatio : $lineHeightValue / $font-value;  
	line-height: $lineHeightRatio;  
}

Ich versuche mich mal daran, das Ganze möglichst "komfortabel" in SASS umzusetzen.

Im Prinzip ändert sich ja quasi nur die Basis-Schriftgröße (und damit verbunden die Basis-Line-Height, wenn man davon ausgeht, dass die Zeilenbreite bspw. konstant 38em beträgt).

Gruß Gunther

[Gunther]

@@Gunnar:

nuqneH

Ich versuche mich mal daran, das Ganze möglichst "komfortabel" in SASS umzusetzen.

Ich hab' da mal was "gebastelt" ...

Im Ergebnis erhält man die 'font-size' und 'line-height' für body,
sowie für alle Hx-Elemente die 'font-size', 'margin-top + bottom' und 'padding-top + bottom'. Und zwar so, dass jedes Hx-Element

• einen margin-top hat, der einer Zeilenhöhe der Basis-Schriftgröße (Gridhöhe) entspricht
• ein ganzzahliges Vielfaches der Gridhöhe einnimmt und vertikal zentriert ist

Dabei bleibt der line-height Faktor jeweils konstant!

  
@function lineHeight($fontSize, $lineWidth) {  
	@if unitless($fontSize) {  
		$fontSize: round($fontSize * $em-base);  
	}  
	@if unitless($lineWidth) {  
		$lineWidth: $lineWidth * $fontSize;  
	}  
	$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 * (1 - $lineWidth / (pow($fontSize * 1.61803398875, 2)));  
	$lineHeightValue : round($fontSize * $lineHeightRatio);  
	$lineHeightRatio : $lineHeightValue / $fontSize;  
	@return $lineHeightRatio;  
}  
  
@mixin vrHeadings ($baseFontSize, $grid, $lineHeight, $fontSize) {  
	$gridLines: $fontSize * $baseFontSize * $lineHeight / $grid;  
	@if $gridLines == floor($gridLines) {  
		$gridLines: floor($gridLines) + 1;  
	}  
	@else {  
		$gridLines: ceil($gridLines);  
	}  
	$padding: (($grid * $gridLines) - ($fontSize * $baseFontSize * $lineHeight)) / 2 / $fontSize / $baseFontSize;  
	  
	font-size: $fontSize * 1em;  
	margin-top: $lineHeight / $fontSize * 1em;  
	margin-bottom: 0;  
	padding-top: $padding * 1em;  
	padding-bottom: $padding * 1em;  
}  
  
@mixin verticalRhythm($bp) {  
	$list: map-get($typo, $bp);  
	$baseFontSize: nth($list, 1);  
	$lineWidth:    nth($list, 2);  
	$h1FontSize:   nth($list, 3);  
	$h2FontSize:   nth($list, 4);  
	$h3FontSize:   nth($list, 5);  
	$h4FontSize:   nth($list, 6);  
	$h5FontSize:   nth($list, 7);  
	$h6FontSize:   nth($list, 8);  
	$lineHeight: lineHeight($baseFontSize, $lineWidth);  
	$grid: $baseFontSize * $lineHeight;  
	  
	body {  
		font-size: $baseFontSize * 1em;  
		line-height: lineHeight($baseFontSize, $lineWidth);  
	}  
	h1 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h1FontSize);}  
	h2 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h2FontSize);}  
	h3 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h3FontSize);}  
	h4 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h4FontSize);}  
	h5 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h5FontSize);}  
	h6 {@include vrHeadings ($baseFontSize, $grid, $lineHeight, $h6FontSize);}  
}  

Das Ganze besteht aus einer (Hilfs-)Funktion und zwei Mixins.
Die Werte kommen aus einer Map ('typo'), die wie folgt aussieht (alle Angaben stellen 'em' Werte dar):

  
$typo: (  
	'bp14':		(1.125, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),  
	'bp15':		(1.25, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),  
	'bp16':		(1.375, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),  
);  

Der Key entspricht (meinen) benannten Breakpoints und die Werte sind

• die Basis-Schriftgröße für body (in r/em)
• die Zeilenbreite in em
• die Schriftgrößen H1 - H6 in em

Der Output sieht dann bspw. für 'bp16' so aus:

  
body {  
    font-size: 1.375em;  
    line-height: 1.5;  
}  
  
h1 {  
    font-size: 2.5em;  
    margin-top: 0.6em;  
    margin-bottom: 0;  
    padding-top: 0.15em;  
    padding-bottom: 0.15em;  
}  
  
h2 {  
    font-size: 2em;  
    margin-top: 0.75em;  
    margin-bottom: 0;  
    padding-top: 0.375em;  
    padding-bottom: 0.375em;  
}  
  
h3 {  
    font-size: 1.5em;  
    margin-top: 1em;  
    margin-bottom: 0;  
    padding-top: 0.25em;  
    padding-bottom: 0.25em;  
}  
  
h4 {  
    font-size: 1.2273em;  
    margin-top: 1.2222em;  
    margin-bottom: 0;  
    padding-top: 0.4722em;  
    padding-bottom: 0.4722em;  
}  
  
h5 {  
    font-size: 1em;  
    margin-top: 1.5em;  
    margin-bottom: 0;  
    padding-top: 0.75em;  
    padding-bottom: 0.75em;  
}  
  
h6 {  
    font-size: 0.87em;  
    margin-top: 1.72414em;  
    margin-bottom: 0;  
    padding-top: 0.11207em;  
    padding-bottom: 0.11207em;  
}  

Damit hat man dann einen vertikalen Rhythmus etabliert, dessen Gridhöhe der Basis-Schriftgröße mal dem line-height Faktor entspricht.

Und zwar unabhängig davon, welche Basis-Schriftgröße der User in seinem Browser eingestellt hat.

Sicher geht das alles noch "eleganter", bzw. lässt sich das vereinfachen, bspw. wenn man immer dieselben Größen für seine Hx Elemente verwendet, oder 'margin-bottom' lässt sich "zentral" auslagern.

Aber es soll ja im Wesentlichen auch nur verdeutlichen, wie ich (m)einen vertikalen Rhythmus etabliere.

Nachteile:
Insbesondere wenn man aufgrund von Mehrspaltigkeit im Layout, mehrere vertikale Rhythmen miteinander "harmonisieren" möchte, machen sich die aufgrund der em-basierten Berechnung auftretenden Rundungsdifferenzen im Browser bemerkbar.

Diese könnte man relativ einfach im Mixin 'vrHeadings' abfangen, allerdings muss man dann wiederum einen Pixelwert für die im Browser eingestellte Basis-Schriftgröße "annehmen".

Für (Verbesserungs-)Vorschläge, Tipps oder weitere Ideen meinen besten Dank im Voraus.

Gruß Gunther

PS: Falls das jemand live ausprobieren möchte, braucht er noch eine Pow Funktion. Diese ist u.a. in Compass enthalten, oder ich verwende bspw. diese:

  
@function pow($val, $pow) {  
	$res: 1;  
	@while($pow > 0) {  
		$res: $res * $val;  
		$pow: $pow - 1;  
	}  
	@return $res;  
}  

[Gunnar Bittersmann]

@@Gunther:

nuqneH

$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 * (1 - $lineWidth / (pow($fontSize * 1.61803398875, 2)));

Wo haste denn *das* her? Aus dem Aprilscherz?

$typo: (
'bp14': (1.125, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
'bp15': (1.25, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
'bp16': (1.375, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
);

Das sieht eher WET als DRY aus.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 \* (1 - $lineWidth / (pow($fontSize \* 1.61803398875, 2)));  

Wo haste denn *das* her? Aus dem Aprilscherz?

Ja! ;-)
Aber mal im Ernst - warum ist das für dich ein "Aprilscherz"?
Ich finde, dass die Formel durchaus sehr "brauchbare" Ergebnisse liefert.

Anders gefragt: Kennst du eine bessere Variante die Zeilenhöhe ins Verhältnis zur Schriftgröße und Zeilenbreite zu setzen?

$typo: (
'bp14': (1.125, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
'bp15': (1.25, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
'bp16': (1.375, 38, 2.5, 2, 1.5, 1.2, 1, 0.87),
);

Das sieht eher WET als DRY aus.

Ja, hatte ich extra dazu geschrieben, dass wenn man "durchgängig" dieselben Größen für seine Hx-Elemente nimmt, man diese auch auslagern kann! :-P

Das sollte ja auch keine "fix & fertige" Sammlung sein, sondern ist eine "quick'n dirty" Variante, die aber im Ergebnis das liefert, was ich haben möchte!

Für meine Zwecke geht es dann eh noch darüber hinaus, weil ich ja teilweise auch noch meine Seitenspalten anpassen und vom vertikalen Rhythmus her harmonisieren will/ muss.

Komme mittlerweile auf halbwegs brauchbare "Verhältnisse" von u.a. 3:4 oder 4:5.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 \* (1 - $lineWidth / (pow($fontSize \* 1.61803398875, 2)));  

Wo haste denn *das* her? Aus dem Aprilscherz?

Ja! ;-)
Aber mal im Ernst - warum ist das für dich ein "Aprilscherz"?
Ich finde, dass die Formel durchaus sehr "brauchbare" Ergebnisse liefert.

Ich hab nicht verstanden, warum die Schriftgröße da quadratisch eingehen soll.

Aber stimmt, ich wollte mir den Artikel noch mal vornehmen – und zerpflücken.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

$lineHeightRatio : 1.61803398875 - 0.30901699437492734189635854149791 \* (1 - $lineWidth / (pow($fontSize \* 1.61803398875, 2)));  

Wo haste denn *das* her? Aus dem Aprilscherz?

Ja! ;-)
Aber mal im Ernst - warum ist das für dich ein "Aprilscherz"?
Ich finde, dass die Formel durchaus sehr "brauchbare" Ergebnisse liefert.

Ich hab nicht verstanden, warum die Schriftgröße da quadratisch eingehen soll.

Ich hab' die Formel auch nicht "analysiert", sondern mir die Ergebnisse für den für mich relevanten Bereich "angeguckt" (Stichwort: Augenmaß) - sah für mich OK aus.

Ist aber eben auch eine der wenigen Formeln die ich gefunden habe, die die Zeilenlänge mit berücksichtigen.

Aber stimmt, ich wollte mir den Artikel noch mal vornehmen – und zerpflücken.

Dann zerpflück' du mal ..., und lass' mich wissen, was dabei herausgekommen ist! ;-)

Ich mache mich in der zwischenzeit mal daran, dass Ganze etwas DRYer zu machen und zusätzlich noch meine Seitenspalten mit einzubauen.

So wie ich das sehe, gibt das leider ein ziemlich "aufgeblähtes" Stylesheet ...!
Wobei das compressed und gzipped ja eigentlich kein Problem darstellen sollte.

Wenn du noch Tipps für mich hast - immer gerne! :-)

Gruß Gunther

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Aber stimmt, ich wollte mir den Artikel noch mal vornehmen – und zerpflücken.

“In the equation above, the optimal line height is produced when h equals the golden ratio (φ).”

Warum der goldene Schnitt das beste Verhältnis zwischen Schreiftgröße und Zeilenabstand sein sollte, wird durch nichts belegt. Dass das gar nicht für alle Schriften stimmen kann, weil diese unterschiedliche x-Höhen haben, wird später beiläufig erwähnt, aber nicht weiter darauf eingegangen.

Häufig verwendete Verhältnisse sind eher kleiner, so im Bereicht 1.4–1.5, nicht φ ≈ 1.618.

Ich hab nicht verstanden, warum die Schriftgröße da quadratisch eingehen soll.

“With the help of basic mathematical modeling, you can make an educated guess that the relationship between the optimal line height and line width is exponential. Here’s the simplest equation to express that:
[latex]w_\phi = l_\phi^2[/latex]”

„Educated guess“ heißt: Ich sauge mir mal eine Formel aus den Fingern?

Mal abgesehen davon, dass der Zusammenhang nicht exponentiell, sondern quadratisch ist, ergibt das keinen Sinn. w und l sind Längen, l² demnach eine Fläche, und eine Länge kann nicht gleich einer Fläche sein.

Wenn man nur mit Zahlenwerten rechnet, ist die Formel von der Einheit abhängig: Für 16 pt ergibt sich:
w = (16φ)² ≈ 670

Rechnet man dasselbe in Millimetern (16 pt * 0.376 mm/pt = 6 mm):
w = (6φ)² ≈ 94.25

Nun sind 94.25 mm / 0.376 mm/pt ≈ 251 pt, was ganz anderes als 670 pt.

Sollte die Formel nur für Pixel gelten? Dann ist sie von der willkürlich festgelegten Größe eines Pixels abhängig – wenn diese denn überhaupt festgelegt wäre. In Retina-Pixel gerechnet käme wieder was ganz anderes raus.

“This is remarkable because now, for the first time, you have a solid mathematical basis for the relationship between font size, line height, and line width.”

Das ist wirklich bemerkenswert. Eben war’s noch ein „educated guess“, so schnell wird „eine solide mathematische Grundlage“ daraus. Schaumschlägerei.

Qapla'

[Gunther]

@@Gunnar Bittersmann:

nuqneH

Aber stimmt, ich wollte mir den Artikel noch mal vornehmen – und zerpflücken.

Deine Analyse und Zerpflückung des Artikels und der darin entwickelten "Formel" ist, wie man es nicht anders von dir gewohnt ist, natürlich mal wieder erstklassig! ;-)

Und ich könnte jetzt zu (fast) jedem einzelnen Punkt eine eigene Abhandlung schreiben. Dazu fehlt mir aber momentan zumindest die nötige Zeit.

Was ich allerdings vermisse, ist eine entsprechende Alternative, außer "Augenmaß", denn das ist ja bekanntlich bei jedem anders (gilt übrigens auch für den/ die "fachlich hilfreich" Bewerter!).

Sehen wir es doch mal so:
Ausgehend von einem "willkürlich" gewähltem Verhältnis, welches sich aber durchaus in anderen Bereichen des Webdesigns auch findet,_und_dem "häufig verwendeten" Augenmaß-Wert zumindest ansatzweise ähnelt, hat der Autor eine "Formel" entwickelt, die unter gewissen Umständen (über die man als Autor eh nur "Mutmaßungen" anstellen kann), basierend auf der Schriftgröße (in Pixeln, die man wiederum basierend auf der Annahme der jeweiligen Basis-Schriftgröße, in EMs umrechnen kann) in Kombination mit der jeweiligen Zeilenlänge (in Pixeln, die man ...), zumindest einen "brauchbaren" Line-Height Faktor liefert.

Auch wenn die Herleitung und Begründung weder mathematisch korrekt, noch sonst irgendwie "richtig" sein mag, so ist das "Ergebnis" aber zumindest als "grober Richtwert/ Anhaltspunkt" imho "zu gebrauchen" - nicht mehr, und nicht weniger!

Ich hatte mich ja auch einige Tage lang intensiv mit dem (verwandten) Thema "vertical rhythm" beschäftigt. Im Ergebnis bin ich für mich zu der Überzeugung gelangt, dass das im Print sicher eine wichtige Rolle spielt (eine äußerst sinnvolle Sache ist), im Webdesign allerdings nur in wenigen Ausnahme-/ Spezialfällen überhaupt praktisch umsetzbar ist, weil es viel zu viele "Unbekannte" gibt, um das praktisch erfolgreich anwenden zu können.

Denn im Endeffekt läuft das auf dasselbe hinaus, wie "pixel perfect design", von dem wir uns ja schon vor Jahren verabschiedet haben!

Ich bleibe also dabei - wer zumindest mal einen groben Anhaltspunkt für seinen Line-Height Faktor, basierend auf Schriftgröße und Zeilenlänge haben möchte, der kann durchaus mit dieser "Formel" rechnen.

Und für das Feintuning empfehle ich dann das "Augenmaß" ...!

Gruß Gunther