Interview mit Mitchell Hashimoto: Ghostty, Zig und Open-Source-Maintenance

• Mitchell Hashimoto entwickelt nach Vagrant, Terraform und Vault nun Ghostty und Vouch und fasst seine Maßstäbe für Terminals, Zig, Open-Source-Maintenance und Produktqualität zusammen
• Ghostty begann als persönliches Projekt, um GPU-Programmierung, Desktop-/Single-Node-Systemprogrammierung und Zig zu lernen, und entwickelte sich mit dem Ziel zu einem schnellen, funktionsreichen nativen Cross-Platform-Terminal
• Terminals sollten nicht wie Browser jede Funktion aufnehmen, sondern die Komponierbarkeit textbasierter Apps, Automatisierung und ein klares Sicherheitsmodell nutzen; der unstrukturierte Byte-Stream von PTYs bleibt dabei eine Grenze
• Open-Source-Maintainer sind Nutzern gegenüber nicht verpflichtet; wer gute Software bauen will, sollte einzelne Requests aber nicht einfach übernehmen, sondern mehrere Probleme in einer konsistenten Funktion lösen
• Große Änderungen in Zig belasten Downstream-Projekte, verbessern aber die Qualität von APIs und Compiler-Werkzeugen; KI könne repetitive Arbeit bei großen Änderungen reduzieren und so die Last der Abwärtskompatibilität senken

---

Warum Ghostty entstanden ist

• Mitchell Hashimoto hat Vagrant, Packer, Consul, Terraform, Vault, Nomad und Waypoint entwickelt und arbeitet derzeit an Ghostty und Vouch
• Ghostty entstand aus dem Problembewusstsein heraus, dass er zwar rund 15 Jahre lang CLI-Anwendungen gebaut hatte, aber nicht wirklich verstand, wie ein Terminal-Emulator funktioniert
• Nach seinem Abschied von HashiCorp wollte er sich wieder mit drei Bereichen beschäftigen
  • GPU-Programmierung im Kontext vor KI
  • Desktop-/Single-Node-Systemprogrammierung, anders als verteilte Systeme
  • Nutzung von Zig
• Das ursprüngliche Ziel war, vim und Compiler auszuführen, Ghostty sich selbst bauen zu lassen und das Projekt danach wegzuwerfen
• Nachdem er sich das Terminal-Ökosystem genauer angesehen hatte, kam er zu dem Schluss, dass es an schnellen, funktionsreichen und nativen Cross-Platform-Tools fehlt
• Nachdem er es mit Freunden auf Discord geteilt hatte, gab es Nutzer, die es täglich verwendeten; der Ghostty-Discord entstand ursprünglich dadurch, dass ein Gruppenchat von Freunden in einen eigenen Bereich umgewandelt wurde
• Weil öffentliche Bekanntheit übermäßige Aufmerksamkeit erzeugen könne, wurde Ghostty lange als private Beta betrieben

Wie weit sollten Terminals erweitert werden?

• Hashimoto lehnt die Richtung ab, Terminals blind zu riesigen Application-Plattformen auszubauen
• Terminals könnten wie Browser oder frühere Java-Runtimes auch Video- und Mikrofonzugriff sowie responsive Layouts aufnehmen, doch Browser, Desktop-Apps und textbasierte Fixed-Width-Grid-Apps hätten jeweils unterschiedliche Stärken
• Textbasierte Anwendungen lassen sich schnell implementieren, sind leicht interaktiv nutzbar und brauchen ein klares Sicherheitsmodell
• Die Stärke terminalbasierter Apps liegt in ihrer Komponierbarkeit
  • Bei TUIs ist das weniger ausgeprägt, aber die meisten CLI-Tools haben über stdin/stdout hinaus Mechanismen, mit denen sie sich wie Funktionen nutzen lassen
  • Die UNIX-Philosophie „Tue eine Sache und tue sie gut“ ist das Extrem davon
  • Neovim und KI-Tools bieten immer mehr Kommandozeilen-Flags an
• Bessere Terminal-Anwendungen führen zu besserer Automatisierung und Skriptbarkeit
• In-Band-Signale von PTYs, also unstrukturierte Byte-Streams inklusive Escape-Sequenzen, bleiben ein großes Problem
• Das Nushell-Ökosystem versucht, dies auf einer separaten Ebene zu beheben, doch Hashimoto hält grundlegendere Verbesserungen für nötig
• Auch wenn viele das Microsoft-Ökosystem nicht mögen, macht PowerShell seiner Einschätzung nach bei strukturierten Daten vieles richtig

Entwurf einer nicht-legacy Terminal-API

• Wenn Hashimoto über eine neue Terminal-API nachdenkt, orientiert er sich an Frameworks großer Application-Plattformen wie Browsern, Emacs, Apple, Microsoft, Android und Spielkonsolen
• Er meint, man müsse zuerst bestehende Vorbilder untersuchen, etwa DOM und JS-APIs im Web, Apples AppKit, Cocoa und SwiftUI, Win32 und WinUI unter Windows sowie GTK und Qt unter Linux
• Schon beim Clipboard-Zugriff sind historische Terminal-Protokolle textzentriert, während Desktops seit Langem mit Bildern und mehreren MIME-Typen umgehen; deshalb müsse man die Clipboard-Dokumentation der jeweiligen Plattformen lesen
• In Ghostty wurde bisher noch kein Custom Protocol eingeführt

• n-screen API

  • Aktuelle Terminals haben üblicherweise zwei Modi: main screen und alt screen
  • Der main screen ist eher Shell und Scrollback, der alternate screen eher Neovim und die meisten TUIs
  • Diese Struktur schaltet zwischen einem der beiden Modi ein oder aus, belegt normalerweise den ganzen Bildschirm und verliert den Scrollback
  • Hashimoto skizziert eine n-screen API, mit der sich unbegrenzt viele Screens im Hintergrund erzeugen und befüllen lassen
  • Screens könnten unterschiedliche Grid-Größen haben und übereinandergelegt werden; der Terminal-Emulator könnte Zeilenumbruch, Auswahl und Routing von Maus-Events übernehmen
  • Wird ein bestimmter Screen als unabhängiges Fenster markiert, könnte der Terminal-Emulator ihn auch außerhalb des Grids rendern
  • Als Beispiel nannte er eine Form, bei der Neovim-Tabs gleichzeitig wie native Fenstertabs geöffnet werden können

• Button-Protokoll

  • Das aktuelle Mausprotokoll kann Events nur empfangen, wenn der Nutzer auf Grid-Zellen des aktuellen Screens klickt
  • Für History-Einträge, die in den Scrollback gewandert sind, lassen sich keine Klick-Events empfangen
  • Terminals unterstützen derzeit das Hyperlink-Protokoll OSC 8
  • Hashimoto denkt über ein Button-Protokoll nach, das ähnlich wie OSC 8 beim Klick eine vom Programm festgelegte Nachricht sendet
  • Ein Button mit der ID open_profile könnte beispielsweise registriert bleiben, auch wenn der Nutzer in die History zurückscrollt
  • Diese Funktion betrifft main-screen-Anwendungen mit Scrollback und hängt mit dem Problem zusammen, dass in main-screen-Apps wie Claude Code das Öffnen von Dateien oder App-internen Links nicht mehr funktioniert, sobald sie in die History wandern

Fehlende Standards und Open-Source-Maintenance

• Hashimoto experimentierte damit, das gesamte PTY-Protokoll durch Wayland zu ersetzen, verwarf den Ansatz aber
• Terminals könne man wie Windowing-Server betrachten, die Fenster und Window-Widgets verwalten; Wayland sei ein gutes Protokoll zur Lösung von Problemen rund um lokale Desktops und Fenster-Rendering
• Eines der Probleme von Terminals sei, dass es keine Standardisierungsorganisation mehr gibt
• Alte Spezifikationen existieren noch, doch die Standardisierung der letzten 20 Jahre orientierte sich daran, was das jeweils populärste Terminal tut
• Dadurch seien viele Funktionen miteinander vermischt worden, und es gebe niemanden, der eine geschmackvolle Vision vorantreibt
• Der weitere Weg sei nicht festgelegt; auch denkbar sei, einen neuen textbasierten Application-Raum zu schaffen, der kein Terminal ist, und darauf eine Terminal-Übersetzungsschicht für Legacy-Apps zu setzen

• Balance zwischen Nutzerwünschen und großer Vision

  • Hashimoto hat öffentlich gesagt, dass Open-Source-Maintainer Nutzern gegenüber null Verpflichtung haben
  • Die erste Zeile einer Open-Source-Lizenz laute „as is, no warranty“; Nutzer erhielten kostenlose Software und hätten im Gegenzug kein Recht, Forderungen zu stellen
  • Gleichzeitig wolle er gute Software bauen und spüre deshalb Verantwortung, Probleme zu beheben und die Software besser zu machen
  • An manchen Tagen schaut er Issues an und behebt Probleme anderer Menschen, an anderen Tagen schaut er weder Issues noch Diskussionen noch PRs an und konzentriert sich auf das, was er selbst will
  • Wenn man jeden Tag nur User-Issues bearbeitet, entsteht stabile, aber stagnierende Software; wenn man jeden PR annimmt, verändert sie sich zwar, verliert aber ihre Vision
  • Die meisten Beiträge kratzten an einem konkreten persönlichen Problem; nehme man sie alle an, häufe sich Code wie ein Berg an
  • Versteht man dagegen das Problem gründlich, lassen sich mehrere Feature-Requests gleichzeitig durch ein elegantes System lösen
  • In einem Video zum Feature-Design nannte er einen Fall, in dem er drei bis vier einzelne Feature-Requests schloss und sie gemeinsam mit einem anderen Feature löste

• Unterschied zwischen Funktionsreichtum und Bloat

  • Eine der am häufigsten gewünschten Funktionen in Ghostty war Suche; sie wurde implementiert und ausgeliefert
  • Einige Nutzer kritisierten, Suche breche mit Ghosttys Minimalismus und blähe es auf, doch Hashimoto antwortete, Ghostty werde als funktionsreiches Terminal beworben
  • Er unterscheidet zwischen Funktionsreichtum und Bloat
  • Die Suchfunktion belegt zwar Speicherplatz auf der Festplatte und wird in den RAM geladen, ist aber so gestaltet, dass kein Code ausgeführt wird, wenn sie nicht verwendet wird
  • Für Nutzer, die sie nicht verwenden, sieht er sie daher als Funktion ohne Laufzeitkosten
  • Ghostty zielt auf ein Terminal, das sich an Nutzerbedürfnisse anpassen lässt, im Default-Zustand funktioniert und Funktionen verbirgt, bis sie gebraucht oder gesucht werden
  • Bei Forderungen, Flags zum Entfernen von Funktionen zu pflegen, sieht er es als dieselbe Art von Forderung, ob ein Maintainer dieses Flag verwaltet oder ein Nutzer einen Fork ohne diese Funktion pflegt

Rechte in Open Source, Veränderungen in Zig und API-Qualität

• Hashimoto glaubt, dass es viel mehr persönliche Forks und gepflegte Forks geben sollte
• Venture-finanziertes Open Source habe eine Generation hervorgebracht, die ausgefeilte Projekte mit Website, bezahltem Supportpersonal und Slack-/Discord-Support erwartet
• Der Kern von Open Source liege jedoch nicht in Produktgarantien, sondern in Freiheit und Rechten
  • Nach Belieben nutzen
  • Verändern
  • Forken
• Stabilität oder Maintenance-Pflichten gehören nicht zu diesen Rechten
• Einen Commit mit einer Sicherheitslücke könne man nicht nur dem Maintainer anlasten; auch Nutzer trügen Verantwortung, wenn sie diesen Commit nicht geprüft haben
• Wer stärkere Garantien und das Recht will, jemandem die Schuld zu geben, müsse für Software bezahlen und eine Vendor-Kunden-Beziehung eingehen
• In persönlichen Projekten kann er auch PRs nicht mergen, die Bugs beheben, die er selbst nicht erlebt
  • Denn ein Merge ist das Versprechen, diesen Code dauerhaft zu pflegen

• Haltung zu Zig

  • Hashimoto wusste, worauf er sich bei der Wahl von Zig einließ, und verstand durch Compiler-Patches die Community, Kultur und Philosophie
  • Die noch nicht begonnene I/O-Änderung dürfte seiner Erwartung nach eine der schwierigsten Arbeiten in Zig werden
  • Zig wird populärer, doch Andrew weicht nicht vor Änderungen zurück, die er für nötig hält; Hashimoto bewertet das als Downstream-Nutzer positiv
  • Zig 0.15 änderte das Writer-Interface und betraf fast allen Code, der Ausgaben erzeugt, doch die API selbst sei dadurch deutlich besser geworden
  • Zig konzentriert sich auf Compiler-Werkzeuge und hat sogar Sprachfeatures entfernt, um die Kompiliergeschwindigkeit zu erhöhen
  • Das gesamte Terminal lib-ghostty lässt sich sofort bauen, aber Andrew hält selbst diese Zeit im Millisekundenbereich offenbar für zu langsam
  • Zig 1.0 werde irgendwann erreicht, sei aber noch einige Jahre entfernt
  • KI könne den Downstream-Schmerz durch Sprachänderungen verringern
  • Nachdem er in verschiedenen Kontexten gezeigt hatte, wie eine Änderung umzusetzen ist, und den Rest anwenden ließ, seien etwa 90 % eines großen Diffs automatisch erledigt worden
  • Wenn man beschreiben kann, wie man von Zustand A zu Zustand B kommt, deute das auf eine Zukunft hin, in der Abwärtskompatibilität weniger Bedeutung hat
  • Ironischerweise im Gegensatz zu Zigs starker Anti-KI-Policy sieht er KI als etwas, das den Schmerz von Änderungen für Downstream-Nutzer abschwächt

• Bibliotheks- und API-Design

  • Die konkreteste Methode für gutes Library-Design ist, viele Libraries aus verschiedenen Communities selbst zu verwenden
  • So wie man Programmiersprachen lernt, die man im Beruf nicht nutzen wird, erweitert die Nutzung von Libraries aus unterschiedlichen Ökosystemen die Perspektive
  • Während des Studiums baute er Spielzeugprodukte in Prolog, Haskell, Clojure und Java und lernte dabei Build-Systeme, Usability, Libraries, Web-Frameworks, Webserver und App-Server der jeweiligen Ökosysteme kennen
  • Die Kultur eines Ökosystems präge die Trennung von Verantwortlichkeiten in Libraries und Frameworks sowie die Form ihrer APIs
  • Als Beispiel für Konzeptübertragung nannte er seine Erfahrung, das in Java lange genutzte Builder Pattern in Ruby auszuprobieren und als brauchbar zu empfinden
  • Docker sah seiner Ansicht nach viele Aspekte von Deployment und Runtime als Teil des Entwicklungsflusses; Vagrant habe bewusst Substantive, CLI und Konfiguration verwendet, die direkt auf Entwicklung fokussiert waren

• Das Dilemma des Tool-Builders und der Tech-Stack

  • Hashimoto sagt, er sei sein Leben lang Tool-Builder gewesen und glaube an das Dilemma des Tool-Builders
  • Man versteht ein Problem dringlich genug, um das ideale Tool zu bauen; wird dieses Tool populär, kann man aber den Kontakt verlieren und zum Tool-Builder werden, der nicht mehr echter Nutzer ist
  • Das Terminal selbst nutzt er täglich, aber TUI-Entwicklung betreibt er nicht ausreichend; er stützt sich auf Maintainer wie rockorager, der mehrere E-Mail- und IRC-Clients pflegt und auch Spezifikationen geschrieben hat
  • Zum aktuellen Tech-Stack hat er eine Haltung von ungefähr „okay“
  • Frontend, TypeScript und die React-Type-Community hätten viele gute Seiten, doch es gebe zu viel Veränderung, hohe Komplexität und unklare Abstraktionsebenen
  • Wie beim Wechsel von HTTP/1 zu HTTP/2 und HTTP/3 sei die Komplexität in vielen Bereichen nichtlinear gestiegen
  • Die Branche bewege sich zu schnell, mache Dinge komplex, die einfacher hätten sein können, und KI sowie zugehörige Tools beschleunigten das

Prinzipien, Kultur, Qualität und Lernen

• Die Prinzipiendokumente von HashiCorp und die Entwicklungsweise von Ghostty seien beide Ausdruck von Hashimotos eigener Person gewesen, weshalb sie sich im Alltag leicht umsetzen ließen
• Setze man sich Prinzipien, die nicht zu einem selbst passen, seien sie wie Neujahrsvorsätze schwer in tatsächliches Handeln zu übertragen
• Ghostty legt Wert auf einen Cross-Platform-Core und native GUIs
  • Der Core ist Cross-Platform
  • Bei der GUI besteht Ghostty nicht auf Cross-Platform, sondern bevorzugt plattformspezifisch native Ansätze
• Open-Source-Projekte und das Internet sollten seiner Ansicht nach Sammlungen unterschiedlicher Stämme sein
• Er mag es nicht, wenn Programmiersprachen zu einem kleinsten gemeinsamen Nenner mit allen Funktionen werden, die jeder will; Einschränkungen schafften Kreativität und Kultur
• Er sagte, er möge Rusts Sprache und Philosophie, aber nicht die Rust-Kultur, und unterschied ausdrücklich, dass das nicht bedeute, Rust-Community-Mitglieder seien schlechte Menschen
• Zig habe in Technik, Community-Management, Finanzierung, PR, Blogposts und Sprechweise klare und polarisierende Positionen; Hashimoto respektiert diese Eigenart und unterstützt Zig deshalb weiterhin finanziell und nutzt es
• Um schnell und mit Qualität zu veröffentlichen, müsse man nicht nur ein konkretes Kundenproblem verstehen, sondern auch den Kontext, in dem Nutzer zu diesem Problem gelangten, und vorgelagerte Probleme
• Wie man das auf Unternehmensebene löst, wisse er nicht; er selbst urteile als intensiver Nutzer der Software, die er baut
• KI könne man für Demos oder zur Prüfung einer Richtung grob einsetzen, aber Code, der veröffentlicht wird, müsse man lesen, verstehen und in guter Qualität ausliefern
• Beim Lernen von C sei wichtiger als die Sprache selbst, zu verstehen, wie Computer funktionieren
  • Man müsse CPU-Scheduling, Speicher, Cache-Hierarchien, Dateisysteme sowie Festplatten- und Dateizugriff verstehen
  • Wer direkt oberhalb der Syscall-Schicht mit C, Zig oder Rust arbeitet, versteht leichter, was passiert
  • Die Dateiöffnungs-APIs von Python, JavaScript und Ruby abstrahieren viele Details weg
  • Auch Funktionen der Standardbibliothek solle man nicht als selbstverständlich ansehen; es sei Code, den jemand geschrieben hat, und man solle ihn selbst lesen und sich hineingraben, um zu verstehen, wie er funktioniert

[unsure4000]

Zur ähnlichen Zeit gepostet, aber die Stimmung ist so unterschiedlich, das ist irgendwie witzig haha
Meine Gedanken zur Rust-Neuschreibung von Bun

[sea715]

• Bei den meisten Streitigkeiten geht es nicht um Ideen, sondern um das Ego
  lol...

[ffdd270]

Hahahahahahahahahahahahahahahahahaha

[GN⁺]

Meinungen auf Lobste.rs

• Ein großartiges Interview; mein Lieblingssatz war: „Ich stimme nicht mit allem überein, aber ich respektiere selbstbewusstes Anderssein wirklich.“
  Ich wünschte, es gäbe mehr von dieser Haltung.

• Wenn man über Präzedenzfälle und die Evolution des Terminals spricht, sollte man Arcan und cat9 zumindest erwähnen.
  https://arcan-fe.com/2022/04/…

• Bei der Stelle „PowerShell kann gut mit strukturierten Daten umgehen“ musste ich an diese Antwort von Jörg W Mittag denken.
  Wenn man typisierte Argumente verwendet, übernimmt PowerShell das gesamte Parsing.
  Auch die Vorstellung, dass Neovim-Tabs gleichzeitig als native Fenster-Tabs geöffnet werden, ist wirklich großartig.
  Direkt oberhalb der System-Call-Schicht zu arbeiten, wie in C, Zig oder Rust, hilft enorm dabei zu verstehen, was tatsächlich passiert.
  Den Abstraktionsschleier zwischen Maschine und Programmierer abzuziehen und zur Grundschicht vorzudringen, macht Spaß und bringt einen näher an den Kern des Problems.
  Standardbibliotheken zielen meist auf Portabilität ab und enthalten daher den kleinsten gemeinsamen Nenner der Betriebssystemfunktionen; Programmieren macht deutlich mehr Freude, wenn man eine Plattform wirklich ausreizen kann.
  Ich habe großen Respekt vor der Haltung, Standardbibliotheksfunktionen nicht als selbstverständlich zu betrachten, sondern sie zu lesen, denn auch sie sind Code, den jemand geschrieben hat.
  Ich würde auch gern mehr über Ghosttys Sponsoring-Programm erfahren. Es scheint als Non-Profit eingetragen zu sein; mich interessiert, wie erfolgreich und tragfähig es ist.

• PowerShell unter Windows hat nach dieser Definition den Vorteil, vollständig intern zu sein, ist aber auf dem .NET-Framework aufgebaut und kann auf nahezu alle Windows-APIs zugreifen und mit ihnen interagieren, sodass es in der Praxis nicht stark eingeschränkt ist.
  UNIX ist von der Anlage her extern, und Nushells strukturierte Antwort ist meines Verständnisses nach strikt intern und damit weniger erweiterbar.
  Oils setzt für externe strukturierte Interoperabilität auf JSON oder die eigene Erweiterung json8, aber beides wirkt im Vergleich zu PowerShell ziemlich eingeschränkt.
  Vielleicht sollten sich einfach alle darauf einigen, nur noch etwas wie msgpack über stdout zu schicken und alle Terminals zu msgpack-Viewern zu machen. Vielleicht sollte man sogar eine Petition starten, Pipe-Serialisierung/-Deserialisierung in libc aufzunehmen.
  Nicht nur sind die Standardisierungsgremien für Terminals verschwunden, auch in der Shell-Welt gab es nach Produktionsmaßstäben kaum Innovation.
  Bash fügt immer noch Funktionen hinzu, die es in der Kornshell bereits gab; Unix-Shells haben viel zu viele Fallen, die niemand zu beseitigen weiß, und POSIX bewegt sich kaum.
  Ich halte immer noch an dem Traum fest, dass Oils oder Nushell in große Distributionen aufgenommen werden und die Leute erkennen, dass Innovation in diesem Bereich etwas Gutes ist.
  Trotzdem hat kitty im Terminal-Bereich eindeutig den Anstoß gegeben, und auch wenn es an Koordination fehlt, scheint immerhin eine Phase erreicht zu sein, in der Innovation stattfindet.

• Ich habe großen Respekt für Mitchells ruhige positive und negative Einschätzungen entwickelt.
  Er baut ein hervorragendes Terminal und mag Terminal-Interfaces, stimmt aber nicht zu, dass das Terminal alles tun oder bis ins Extrem getrieben werden sollte.
  Er kümmert sich intensiv um Programmiersprachen und ihre Communities und möchte, dass jede Sprache ihre eigene Gestalt hat, weiß aber auch, dass Sprachen letztlich Mittel zum Zweck sind und ein Verständnis der Grundlagen wichtiger ist.
  Er räumt ein, dass er die Rust-Community persönlich nicht mag, wertet aber Menschen nicht ab, die anders empfinden.
  Beeindruckend ist diese ziemlich zenartige Haltung: das Internet als Sammlung vieler Stämme zu sehen, ohne in Tribalismus oder die Suche nach dem „einzig wahren Stamm“ zu verfallen.

• Ich stimme der Idee zu, dass es mehr persönliche Maintainer-Forks geben sollte, bin mir aber nicht sicher, wie man das fördern kann.
  Am unteren Ende des Anspruchsdenkens interessiert man sich vielleicht nicht für unternehmensnahe Dinge wie bezahlte Supportverträge, sondern will nur die Bequemlichkeit, etwas unverändert über den bevorzugten Paketmanager installieren zu können.
  Die anfängliche Reibung beim Wechsel von brew install oder apt install hin zum Umgang mit geklonten Repositories und Build-Tools muss irgendwie reduziert werden.
  Schnellere Compiler könnten helfen.
  Bei sicherheitssensibler Software kann es allerdings im Interesse aller liegen, dass Nutzer nicht zu viele Änderungen vornehmen; manchmal ist diese Reibung selbst ein Feature.

• Ich stimme nachdrücklich zu, dass moderne UIs etwas brauchen, das ungefähr zwischen n-screen und Button-Spezifikation liegt.
  Vielleicht reicht es schon, das eine semantische Ebene zu nennen.
  Mit einer solchen Ebene würden agentenartige Tools oder Main-Screen-Tools, Accessibility, kombinierbare Widgets und Controls und Ähnliches möglich.
  n-screen und Buttons wirken letztlich wie die linken und rechten Grenzen dafür, wie viel Inhalt man ausdrückt.
  Idealerweise sollte diese semantische Ebene auch Dinge wie mehrere Cursor, Wortumbruch statt zeichenweisem Zeilenumbruch sowie Overlays (z-index, Cell Blending usw.) mitbringen.