Buttons korrekt ausrichten

[Rolf B]

Hallo alle,

Vertical Alignment bringt mich noch um den Verstand.

Ich hab da zwei Buttons. Einer hat Text mit Subscript. Wie kriege ich es hin, dass die Texte beider Buttons auf einer Linie sind und die Buttons auf gleicher Höhe? Und zwar ohne Pixelfrickelei.

Also so ein Billig-HTML, bis auf das ₁₀.

<p>Funktionen: 
  <button name="wurzel">Wurzel</button>
  <button name="logarithmus">log<sub>10</sub></button>
</p>

Wenn ich es einfach so lasse, richtet der Browser (Chrome) die Texte in Normalschrift auf einer Linie aus. Das Subscript in einem Button führt dazu, dass der Textinhalt des Buttons im Button nach oben rutscht. Und damit der ganze Button, durch die Baseline-Ausrichtung, nach unten.

Ich kriege es nicht hin, den Subscript-haltigen Text im Button so auszurichten wie den Subscript-freien Text. Ein vertical-align auf die Buttons bringt die Buttons auf Linie, aber dann ist "Wurzel" und "log" nicht auf einer Linie. Eine Flexbox hat den gleichen Effekt.

Zur Visualisierung ein jsfiddle mit großem Font und einer zurechtgeschobenen Hilfslinie, damit man die Verschiebung sieht. Ich hoffe, es passt halbwegs auf anderen Browsern…

Das vierte Beispiel ist dann ein mit transform hingefummeltes "So soll es aussehen". Visuell. Aber dieses CSS will ich nicht.

https://jsfiddle.net/Rolf_b/3Lm6ewx4/

Rolf

[Rolf B]

Nachtrag: Unicode-Subscripte, also log₁₀ statt log₁₀, retten den Tag nicht. Je nach Fonts sind die Buttons dann verschieden hoch oder, wenn man eine height setzt, gegeneinander verschoben.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Nachtrag: Unicode-Subscripte, also log₁₀ statt log₁₀, retten den Tag nicht.

Sie retten aber die Darstellung. (Abb. 1) (Die Rettung des Tages hat Matthias ja schon gezeigt.)

s.a. Codepen

Allerdings werden bei etlichen Browser/Screenreader-Kombinationen die Subscript-Zeichen ₁₀ nicht als „zehn“ vorgelesen.^[1]

<sub> verkleinert die Schrift – aber nicht genug. (Abb. 2)

Wenn man die Schrift noch weiter verkleinert, wird das Dilemma noch deutlicher sichtbar: Es passt nicht zusammen; die Strichstärke der Subscripts ist viel zu gering, da ja mit der Größe verkleinert. (Abb. 3)

Mit bold wird’s dann aber zu fett. (Abb. 4)

Die Darstellung rettet ein OpenType-Feature: subs. Schriftgröße und vertikale Ausrichtung werden zurückgesetzt und OpenType sorgt dafür, dass die Subscript-Zeichen gesetzt werden. (Abb. 5)

Das geht für Ziffern, auch für + und − (Minus, nicht Bindestrich!), nicht aber für beliebige Zeichen. Und natürlich muss man Fonts verwenden, die dieses OpenType-Feature unterstützen.

🖖 Живіть довго і процвітайте

---

1. VoiceOver mit Safari oder Chrome auf Mac: wie erwartet log₁₀ – „log“; log<sub>10</sub> – „log zehn“;
   VoiceOver mit Firefox auf Mac: log₁₀ – „log zehn“ (ui!); log<sub>10</sub> – „log“, Inhalt von sub-Elementen wird nicht angesagt (WTF‽) Da VoiceOver aber sowieso mit Safari am besten zusammenspielt, würde ich der VoiceOver/Firefox-Kombination keine besondere Relevanz zukommen lassen. ↩︎

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Ich hab den Codepen nochmal angepasst: statt font-feature-settings: 'subs' lässt sich auch (besser) font-variant-position: sub verwenden.

Entsprechendes gibt’s natürlich auch für hochgestellte Zeichen (superscripts): HTML-Element sup, OpenType-Feature sups. Auf dieser Seite schon seit geraumer Zeit im Einsatz.

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

font-variant-position ist derzeit noch Firefox-only. Die font-feature-settings funktionieren auch in Chrome. Aber der Umstand, dass man dafür dann einen Font braucht, der das unterstützt, ist auch wieder zum Ko...llabieren.

Aber das sind doch alles Workarounds um eine blödsinnige Macke des Browsers: Ich füge einem Button einen (vorlesbaren) Subscript-Text hinzu, und alles verschiebt sich. Dass Buttons inline-block Elemente sind, scheint der Hauptauslöser des Dramas zu sein. Mit span-Elementen, die den gleichen Inhalt haben, passiert das nicht. Mache ich die spans inline-block (sprich: ein flow-root), dann ist es geschehen.

Ich sehe jedenfalls nicht ein, typographische Expertenfeatures, die auch nur mit bestimmten Fonts funktionieren, als Standardwerkzeug anzusehen. Mit den font-feature-settings klappt's auch bei mir, aber nur für Calibri. Nicht für den Button-Default-Font von Windows - Arial.

Und jetzt komm mir nicht mit progressive enhancement. 2023 auf PE zu zeigen, wenn Subscripte nicht brauchbar funktionieren, kann es nicht sein. Mann mann mann, was regt mich das auf. Nein, du regst mich nicht auf, Gunnar. Der Browser.

Ich werde in dem Wiki-Beispiel, wegen dem das alles entstand, die position:relative; top: 0.3em Variante verwenden und als Workaround erwähnen. Dass die Subscript-Zeichen zu groß sind, nehme ich hin. Die tiefgestellte 10 war nur als visueller Gimmick gedacht und nicht als Thema des Artikels.

Beim <sub> Element muss ich dann aber mal schauen, wie ich dieses Thema im Wiki aufarbeite. Einen Artikel zu Baselines haben wir zwar, aber auf solche Fallstricke geht das nicht ein.

Und ich bin vermutlich auch der falsche Autor dafür. Baselines, das ist ein zu eckiges Konzept für meinen runden Kopf - zumindest passiert da nie das, was ich zu erwarten glaube 😟

Rolf

[Gunnar Bittersmann]

@@Rolf B

font-variant-position ist derzeit noch Firefox-only.

Nein. Auch Safari. Und auch Chrome. Hängst du da eins, zwei Updates zurück? Oder kann der Chrome 112 auf macOS mehr als der auf Windows? Edge 112 hinkt da hinterher. Verwendet der eine ältere Chromium-Version als Chrome 112?

Aber der Umstand, dass man dafür dann einen Font braucht, der das unterstützt, ist auch wieder zum Ko...llabieren.

Dass man für OpenType-Features auch OpenType-Fonts braucht, sollte jetzt nicht überraschen. Bei Georgia gibt’s auch keine automatisch gesetzen Ligaturen.

Mit den font-feature-settings klappt's auch bei mir, aber nur für Calibri. Nicht für den Button-Default-Font von Windows - Arial.

Dann verwende halt nicht Arial. Arial ist sowieso keine gute Textschrift und eine noch schlechtere Display-Schrift. „Sie wird genommen, weil sie im Computermenü … ganz oben steht. Würde sie Zarial heißen, hätte sie kein Mensch genommen.“ — Erik Spiekermann

Es ist ja nicht so, dass es unter Windows keine vernünftigen Systemschriftarten gäbe.

Aber das sind doch alles Workarounds um eine blödsinnige Macke des Browsers: Ich füge einem Button einen (vorlesbaren) Subscript-Text hinzu, und alles verschiebt sich.

Manchmal ist die Macke nicht im Browser, sondern davor. 😝 Du verschiebst einen Teil des Textes vertikal (Browserdefault: sub { vertical-align: sub }), sodass seine Zeilenbox aus der des übrigen Textes herausragt. Was soll der Browser da anderes tun als das auszugleichen, indem er dem Text unten mehr Platz zur Verfügung stellt? Und da du dem Button eine feste Höhe verpasst hast, fehlt dann oben ein Stück.

Ich sehe jedenfalls nicht ein, typographische Expertenfeatures, die auch nur mit bestimmten Fonts funktionieren, als Standardwerkzeug anzusehen.

Oje, ist es allgemein um Grundkenntnisse in Typografie so schlecht bestellt, dass man mit geringen Kenntnissen schon als Experte gilt?

Beim <sub> Element muss ich dann aber mal schauen, wie ich dieses Thema im Wiki aufarbeite.

Indem du sagst, dass der Browserdefault dafür bestenfalls als Fallback taugt. Die Gründe hatte ich genannt.

🖖 Живіть довго і процвітайте

[Matthias-nicht-angemeldet]

Beim <sub> Element muss ich dann aber mal schauen, wie ich dieses Thema im Wiki aufarbeite.

Indem du sagst, dass der Browserdefault dafür bestenfalls als Fallback taugt. Die Gründe hatte ich genannt.

Was spricht denn gegen :

Wenn Sie Super-und Subtext verwenden, schieben Sie Glyphen aus der „normalen“ Zeilenhöhe heraus. Deshalb sollten Sie den Wert für line-height höher setzen.

Zusätzlich könnten mit Open-Type-Fonts …

Herzliche Grüße

Matthias

[Gunnar Bittersmann]

@@Matthias-nicht-angemeldet

Was spricht denn gegen :

Wenn Sie Super-und Subtext verwenden, schieben Sie Glyphen aus der „normalen“ Zeilenhöhe heraus. Deshalb sollten Sie den Wert für line-height höher setzen.

Dagegen spricht, dass man nicht die Zeilenhöhe für den gesamten Text einer Seite ändert, nur weil man an einer Stelle etwas Hoch- oder Tiefgestelltes hat.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Ich bin ja jetzt ganz gewiss nicht derjenige, der an Feinheiten der Textgestaltung ein wirkliches Interesse hat (und halte mich deswegen eigentlich raus). Aber hier geht es um Aussagelogik(¹):

Was spricht denn gegen :

Wenn Sie Super-und Subtext verwenden, schieben Sie Glyphen aus der „normalen“ Zeilenhöhe heraus. Deshalb sollten Sie den Wert für line-height höher setzen.

Dagegen spricht, dass man nicht die Zeilenhöhe für den gesamten Text einer Seite ...

Also wenn viele oder meinetwegen alle Browser aus $Gründen(²) ein Default-Stylesheet mitbringen, welches für Buttons mit hoch- oder tief gestellten Text unerwünschte Ergebnisse liefert, dann muss man das bei Verwendung von hoch- oder tief gestellten Text im eigenen Stylesheet für (alle oder bestimmte) Buttons korrigieren. Ich finde jetzt bei nichts bei Matthias mit dem er sagt, dass er diese Korrekturen bzw. Settings für den gesamten Text einer Seite vorschlägt.

---

¹) Nein, ich erwähne nicht im Haupttext, dass ganze Prädikatsjuristenkollektive bei mir mal einen Kurs darin belegen sollten um zu vermeiden, dass diese nach Fehlversuchen als idiotische Blahfasler dastehen.

²) Einer davon könnte sein, das die pauschale Berücksichtigung des in Buttons eher selten hoch- oder tief gestellten Textes bei der übergroßen Mehrheit der Websites zu Wertungen wie „platzverschwendend“ und/oder „augenkrebsverursachend“ führt. (Es sei denn natürlich, man geht davon aus, dass Webseiten in großer Zahl einen wissenschaftlichen Taschenrechner als tolles Extra implementieren...)

[Gunnar Bittersmann]

@@Raketenwilli

Also wenn viele oder meinetwegen alle Browser aus $Gründen(²) ein Default-Stylesheet mitbringen, welches für Buttons mit hoch- oder tief gestellten Text unerwünschte Ergebnisse liefert, dann muss man das bei Verwendung von hoch- oder tief gestellten Text im eigenen Stylesheet für (alle oder bestimmte) Buttons korrigieren. Ich finde jetzt bei nichts bei Matthias mit dem er sagt, dass er diese Korrekturen bzw. Settings für den gesamten Text einer Seite vorschlägt.

Es ging um diesen Abschnitt im Wiki: vertical-align ganz allgemein, nicht speziell für Buttons.

🖖 Живіть довго і процвітайте

[Raketenwilli]

Es ging um diesen Abschnitt im Wiki: vertical-align ganz allgemein, nicht speziell für Buttons.

Überleg mal GENAU, warum mich das nicht überzeugt.

[Matthias Scharwies]

Guten Morgen!

Ich war gestern unterwegs und konnte erst heut' ins Wiki:

• HTML/Tutorials/Textauszeichnung#hoch-_und_tiefgestellter_Text

• HTML/Elemente/sub war mein Ausgangspunkt - der verlinkte auf HTML/Textauszeichnung/subund dieser wieder auf … die Referenz. - Der Link geht jetzt auf diesen neuen Abschnitt.

@Rolf B Ich würde weiterhin nur die Zeilenhöhe ändern. Grad geschaut: Unser CSS gibt jedem p line-height: 1.5em - auch support.microsoft.com nimmt 1.5 ohne Einheit - translate ist zwar auch ok, aber imho schon zu kompliziert.

Herzliche Grüße

Matthias Scharwies

PS: Geiler Sonnenschein - jetzt geht's raus mit dem Rad!

[Gunnar Bittersmann]

@@Gunnar Bittersmann

font-variant-position ist derzeit noch Firefox-only.

Nein. Auch Safari. Und auch Chrome. Hängst du da eins, zwei Updates zurück? Oder kann der Chrome 112 auf macOS mehr als der auf Windows? Edge 112 hinkt da hinterher.

Edge 113 immer noch.

Verwendet der eine ältere Chromium-Version als Chrome 112?

---

Und wo wir gerade beim Beschweren über Minuspunkte sind: Wofür genau hab ich hier einen bekommen?

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

wo Du nach dem Minus fragst - ein paar Sticheleien hast Du Dir schon gegönnt.

Manchmal ist die Macke nicht im Browser, sondern davor.

Das 😝 wurde vielleicht missdeutet.

Oje, ist es allgemein um Grundkenntnisse in Typografie so schlecht bestellt, dass man mit geringen Kenntnissen schon als Experte gilt?

Typographie ist kein Allgemeinwissen. Zumindest bei mir ist das ein exotisches Randgebiet. Deswegen, ja, selbst als Einäugiger mit grauem Star wärest Du da schon mein König. Und angesichts der Vorträge, die Du zum Thema schon gehalten hast, sind Deine Kenntnisse sicher nicht „gering“.

Du verschiebst einen Teil des Textes vertikal (Browserdefault: sub { vertical-align: sub }), sodass seine Zeilenbox aus der des übrigen Textes herausragt. Was soll der Browser da anderes tun als das auszugleichen, indem er dem Text unten mehr Platz zur Verfügung stellt?

Er soll die Baseline des nicht gesubten Textes da lassen, wo sie ist. Was ist denn daran so schwierig?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Er soll die Baseline des nicht gesubten Textes da lassen, wo sie ist. Was ist denn daran so schwierig?

Nichts, denn genau das tut er ja, wenn du ihm nichts anderes sagst. Testseite:

Abb. 1: Grundlinien der Buttons auf derselben Höhe. Wenn da ein Element ist, das nach unten mehr Platz braucht, wird der Button eben höher.

Abb. 2: Grundlinien der Buttons immer noch auf derselben Höhe, wenn du den Buttons eine feste Höhe gibst. Da die Unterkante des zweiten Buttons wegen des Elements, das nach unten mehr Platz braucht, tiefer liegt als die des ersten, tut das auch die Oberkante.

Abb. 3: Wenn du Ober- und Unterkanten der Button in Übereinstimmung bringst, stimmen natürlich die Grundlinien nicht mehr überein. Wie sollten sie auch?

Abb. 4: Wenn da kein Element ist, das nach unten mehr Platz braucht, stimmen Ober- und Unterkanten und Grundlinien überein.

Dein Problem resultierte aber allein daraus, dass du die „10“ scheiße aussehen lassen wolltest. Wenn man es richtig macht, tritt das Problem gar nicht erst auf:

Abb. 5: Subscript-Zeichen. (VoiceOver liest die auch richtig vor: „zehn“, nicht „eins null“. Was andere Screenreader daraus machen, kann ich nicht sagen.)

Abb. 6: OpenType-Feature. Gibt es irgendeinen Grund, keine OpenType-Schriften zu verwenden?

🖖 Живіть довго і процвітайте

[Rolf B]

Hallo Gunnar,

OpenType-Feature. Gibt es irgendeinen Grund, keine OpenType-Schriften zu verwenden?

Nein, gibt es nicht. Es gibt für mich aber durchaus einen Grund, zu erwarten, dass ich nicht aufwändig am sub-Element herumkonfigurieren muss, damit bei Vorhandensein einer geeigneten Schrift das Ergebnis von Fig. 6 herauskommt.

Wenn da ein Element ist, das nach unten mehr Platz braucht, wird der Button eben höher.

Das sub-Element ist genau dafür da, Indizes zu notieren. Ich erwarte, dass <sub> den Platzbedarf der Textzeile eben NICHT vergrößert. Wenn mir im Ergebnis die Indizes oder Exponenten zu sehr in die Nachbarzeilen hineinragen, kann ich mit line-height gegensteuern. Was aber auch nach hinten losgehen kann, wegen der Eigenschaft des Browsers, den Button irgendwie um die line-height herum zu zentrieren. Mache ich height=line-height, steht der Text zu tief. Ich muss sie also "etwas" kleiner machen. Mache ich die line-height aber zu klein, sind die Buttons nicht ausgerichtet. Was "zu klein" ist, dürfte vom Font abhängen.

Genau das soll die Mistkarre alleine erledigen, ohne von sub oder sup zerrissen zu werden. Ohne von mir eine Professur in Typographie zu erwarten, Tricksereien am sub-Element oder die Verwendung von exotischen Unicodezeichen wie ₁₀. DAS erwarte ich. Dir mag der Einsatz dieser Features trivial und ganz natürlich vorkommen. Aber das ist umgekehrtes Dunning-Krüger: Du bist dermaßen Experte, dass Dir dein Level normal vorkommt.

Oder ich bin einfach zu doof und erwarte zu viel. Kann ja auch sein.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Das sub-Element ist genau dafür da, Indizes zu notieren. Ich erwarte, dass <sub> den Platzbedarf der Textzeile eben NICHT vergrößert.

Dann setz dich halt in den DeLorean und ändere die Browserdefaults.

Oder: wenn dir die Browserdefaults nicht gefallen, überschreib sie. Dazu ist CSS schließlich da. Und warum nennst du die Verwendung von CSS dazu, wozu es da ist

Tricksereien am sub-Element

? Höre ich da einen negativen Unterton raus?

Verwendung von exotischen Unicodezeichen wie ₁₀.

Warum sind tiefgestellte Zeichen zur Verwendung als tiefgestellte Zeichen exotisch? Und was sind für dich exotische Unicodezeichen? Alle ab U+0080, he?

Aber das ist umgekehrtes Dunning-Krüger: Du bist dermaßen Experte, dass Dir dein Level normal vorkommt.

Ich hänge öfter mit Experten ab, sodass mir mein Level ziemlich niedrig vorkommt.

🖖 Живіть довго і процвітайте

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Ich hab da mal eine Präsentation draus gemacht: TIL about H₃O⁺ + OH⁻.

🖖 Живіть довго і процвітайте

[Gunnar Bittersmann]

@@Gunnar Bittersmann

VoiceOver mit Safari oder Chrome auf Mac: wie erwartet log₁₀ – „log“;

Weiß nicht, was ich damals gehört haben will. VoiceOver mit Safari oder Chrome auf Mac liest „log zehn“.

VoiceOver mit Firefox auf Mac: log₁₀ – „log zehn“ (ui!); log<sub>10</sub> – „log“, Inhalt von sub-Elementen wird nicht angesagt (WTF‽)

Das kann ich nachvollziehen.

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Guten Morgen!

Hallo alle,

Vertical Alignment bringt mich noch um den Verstand.

Ich hab da zwei Buttons. Einer hat Text mit Subscript. Wie kriege ich es hin, dass die Texte beider Buttons auf einer Linie sind und die Buttons auf gleicher Höhe? Und zwar ohne Pixelfrickelei.

Also so ein Billig-HTML, bis auf das ₁₀.

<p>Funktionen: 
  <button name="wurzel">Wurzel</button>
  <button name="logarithmus">log<sub>10</sub></button>
</p>

Wenn ich es einfach so lasse, richtet der Browser (Chrome) die Texte in Normalschrift auf einer Linie aus. Das Subscript in einem Button führt dazu, dass der Textinhalt des Buttons im Button nach oben rutscht. Und damit der ganze Button, durch die Baseline-Ausrichtung, nach unten.

Ich kriege es nicht hin, den Subscript-haltigen Text im Button so auszurichten wie den Subscript-freien Text. Ein vertical-align auf die Buttons bringt die Buttons auf Linie, aber dann ist "Wurzel" und "log" nicht auf einer Linie. Eine Flexbox hat den gleichen Effekt.

Zur Visualisierung ein jsfiddle mit großem Font und einer zurechtgeschobenen Hilfslinie, damit man die Verschiebung sieht. Ich hoffe, es passt halbwegs auf anderen Browsern…

https://jsfiddle.net/Rolf_b/3Lm6ewx4/

Ich habe bei .t2 noch eine line-height eingefügt - wäre das schon eine magic number?

.t2 button {
  vertical-align: middle;
  line-height: 1.5em;
}

BTW: Im Firefox sah es ja schon vorher gut aus; jetzt auch im Chrome!

Herzliche Grüße und ein schönes langes Wochenende!

Matthias Scharwies